# Description of Changes
Provides new WASM ABIs:
- `datastore_index_scan_point_bsatn`
- `datastore_delete_by_index_scan_point_bsatn`
These are then used where applicable to speed up `.find(_)` and friends.
Point scans are also used more internally where applicable.
What remains after this is use in C# module bindings and to expose this
in TS as well.
The PR makes TPS go from roughly 36k to 38k TPS on my machine and also
makes a difference in flamegraphs where the time spent in some index
scans are substantially decreased.
# API and ABI breaking changes
None
# Expected complexity level and risk
3? This touches the datastore an how we expose it to modules.
# Testing
Some existing tests now exercise the new ABIs by changing what
`.find(_)` and friends do.
---------
Signed-off-by: Mazdak Farrokhzad <twingoow@gmail.com>
`reqwest` includes the full URL in its errors, including query params.
This is unfortunate, as query params can contain sensitive info like API tokens.
It's difficult for modules to clean these themselves, as they see errors as strings,
losing the structure of `reqwest::Error`.
In this commit, we strip query parts out of URLs in errors before returning them to modules.
I've also audited all of the error return paths in the `http_request` method
and left comments justifying why the unchanged ones are safe.
# Description of Changes
We were using `rust-toolchain` in some places, and `rust-toolchain-file`
in others. I think Rust released a new version, which made the
`rust-toolchain` parts break with:
```
info: downloading component 'rustfmt'
info: removing previous version of component 'rust-src'
info: rolling back changes
error: could not rename component file from '/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/term/terminfo/searcher' to '/root/.rustup/tmp/a4eo07uz83vsyfhk_dir/bk': Invalid cross-device link (os error 18)
Error: Process completed with exit code 1.
```
(Separately, this breakage is confusing.. we'll probably run into this
again when we roll forward our rust version..)
# API and ABI breaking changes
None. CI-only change.
# Expected complexity level and risk
1
# Testing
- [x] CI passes
- [x] There are no more instances of `rust-toolchain`:
```
$ grep -rIP 'rust-toolchain(?!-file)' .github/workflows
.github/CODEOWNERS:/rust-toolchain.toml @cloutiertyler
```
(on `master`, this finds the instances we changed)
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Uses `with_host_stack` to provide a `StackCreator` that pools
`FiberStack`s.
This does not use the pooling instance allocator and is limited to just
stacks.
# API and ABI breaking changes
None
# Expected complexity level and risk
3? Some unsafe and wasmtime internals relied upon.
# Testing
Covered by existing tests.
# Description of Changes
This changes the ci runs to execute `cargo ci` instead of running
commands directly from the github workflow.
The goal here is to unify the commands under `cargo ci` so that it's
easier and more intuitive to run locally
# API and ABI breaking changes
There are no API/ABI changes.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
Complexity: 1
It is not a complex change as it is mostly localized to the ci runs and
is easily reversible if something goes wrong. The biggest risk here is
to have future CI runs break, which can be remediated by reverting these
changes.
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] run `cargo ci` and its subcommands locally
- [x] run the github workflow against this branch to check if the CI
jobs are working properly.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Signed-off-by: Roberto Pommella Alegro <robertoaall@gmail.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Fixes https://github.com/clockworklabs/SpacetimeDB/issues/3617.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
A proptest `empty_range_scans_dont_panic` is added.
# Description of Changes
As title.
# API and ABI breaking changes
incremental binding.
# Expected complexity level and risk
# Testing
Unit and smoketest
# Description of Changes
fixes#3861.
While running prechecks for automigration, the `range` passed to
`iter_by_col_range_mut` was of type `AlgebraicValue::I128`, even though
it should have matched the column’s type.
Fix is straightforward by introducing `AlgebraicValue::from_i128`
helper.
# API and ABI breaking changes
NA
# Expected complexity level and risk
1
# Testing
- Modified smoketest to repro reported bug.
---------
Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
# Description of Changes
Fixes#3827
Adding lte and gte support for query_builder in rust.
# API and ABI breaking changes
Incremental change to bindings.
# Expected complexity level and risk
1
# Testing
unit test and smoketest
# Description of Changes
Don't throw an error if there is no `reducerInfo`. The code was
previously trying to handle the case of an unknown reducer, but was
effectively asserting that the reducerInfo existed too soon.
Now we should be fine handling a transaction, even if we can't determine
reducer information for it.
# Expected complexity level and risk
1.
# Testing
I tested this by running the quickstart chat app, and using the CLI to
delete rows (via `spacetime sql`). Before this change, the client
errors, but now it handles it correctly.
I also tested with the repro in
https://github.com/clockworklabs/SpacetimeDB/issues/3817
# Description of Changes
This should fix part of #3503. Adds an override modifier to generated
code and fixes a warning from the angular compiler.
# Expected complexity level and risk
1
# Testing
- [x] Code works fine with the added `override` modifier.
- [ ] Perhaps we should have an angular test project?
# Description of Changes
This makes it possible to insert new pages between existing pages
without renaming the existing pages.
I also added a section to docs/README.md with procedure for how to name
new pages, which I'll paste here:
### Adding new pages
All of our directory and file names are prefixed with a five-digit
number which determines how they're sorted.
We started with the hundreds place as the smallest significant digit, to
allow using the tens and ones places to add new pages between.
When adding a new page in between two existing pages, choose a number
which:
- Doesn't use any more significant figures than it needs to.
- Is approximately halfway between the previous and next page.
For example, if you want to add a new page between `00300-foo` and
`00400-bar`, name it `00350-baz`. To add a new page between `00350-baz`
and `00400-bar`, prefer `00370-quux` or `00380-quux`, rather than
`00375-quux`, to avoid populating the ones place.
To add a new page after all previous pages, use the smallest multiple of
100 larger than all other pages. For example, if the highest-numbered
existing page is `01350-abc`, create `01400-def`.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1 - @JulienLavocat said this wouldn't break anything.
# Testing
None.
---------
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
Mainly a smoketest to exercise the intended behaviour. Also return an
error if we end up delegating to the reset database endpoint, which
itself doesn't accept a `parent` parameter.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Updated package sizes from a failed release dry-run:
https://github.com/clockworklabs/SpacetimeDBPrivate/actions/runs/20045893743/job/57491806595
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None
# Expected complexity level and risk
1 - this is just a release fix
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
I have not tested this, it is a trivial change.
RFC 6455, Section 5.4 describes message fragmentation, and we can do
that with tungstenite.
It does seem to help getting control messages (ping, pong, close)
through without head-of-line blocking.
# Expected complexity level and risk
2 - Need to test with clients
# Testing
TBD - some more abstraction is needed due to the difficulty of
synthetically producing a large outgoing message.
# Description of Changes
Uses the `sourcemap` crate to map text locations in the bundle to text
locations in the original source code.
# Expected complexity level and risk
1 - essentially only related to diagnostics
# Testing
- [x] Manually tested
- [ ] Add an automated test for backtrace output
# Description of Changes
As title
# API and ABI breaking changes
NA
# Expected complexity level and risk
0
---------
Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
Fixes the following issues:
1. When dropping a view, we deleted its row from `st_view`, but didn't
drop the backing table.
2. `delete_col_eq` returned a nonsensical error if the delete set was
empty.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
- [x] Auto-migrate smoketests
# Description of Changes
This reapplies the patch from #3704, and fixes the issues that were
causing it to deadlock.
The reason it was deadlocking was that it allowed for the following
sequence of events:
* `SchedulerActor::handle_queued()` begins mutable tx
* `ModuleHost::disconnect_client()` submits call to `call_reducer(tx:
None)`
* scheduler submits call to `call_reducer(tx: Some)`
* `WasmModuleInstance::disconnect_client` now has to try to take tx
lock, but the scheduler's call_reducer already holds it and is behind it
in the queue
So, I moved most of the logic from `handle_queued` back to being
executed in the module worker thread, but kept the code in
`scheduler.rs` so that it can all be reasoned about locally.
Fixes#3645. Should I uncomment the implementation of
`ExportFunctionForScheduledTable for F: Procedure` now?
# Expected complexity level and risk
2 - there's a chance that this patch hasn't fully fixed the deadlock
issue from #3704, but I'm quite confident.
# Testing
- [x] Manually verified that deadlock no longer occurs - previously,
`while true; do python -m smoketests schedule_reducer -k
test_scheduled_table_subscription; done` would freeze up in only 2 or 3
iterations, but now it can run for 10 minutes without issues.
# Description of Changes
In the past we've been converting CPU instructions into energy. We are
not doing it on the SpacetimeDB side anymore, thus we should report the
WasmTime fuel directly
# Description of Changes.
fixes#3715
The patch makes snapshots to skip ephemeral tables.
# API and ABI breaking changes
NA
# Expected complexity level and risk
1
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- maybe a test you want to do -->
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
This adds a way to build queries with typescript views, and it allows
views to return queries (if the return type of the query is an array).
For examples and syntax, you can look at the tests in
[crates/bindings-typescript/tests/query.test.ts](https://github.com/clockworklabs/SpacetimeDB/compare/jsdt/ts-query-builder?expand=1#diff-4fd25c191f1207085a491cf84996c601f805f5e8280d1cf2a812ebad6aa6e75a).
To play around with the syntax, you might find it easier to look in
[crates/bindings-typescript/src/server/view.test-d.ts](https://github.com/clockworklabs/SpacetimeDB/compare/jsdt/ts-query-builder?expand=1#diff-4fd25c191f1207085a491cf84996c601f805f5e8280d1cf2a812ebad6aa6e75a).
This could still use some cleanup, and there are some places where the
type safety is imperfect. I'll try to list the known limitations here:
1. This will allow the use of `eq` for columns that are product types,
even though the query engine doesn't support it. This can be fixed
later, and it would only be a breaking change for modules that have
invalid queries.
2. When we check if a view is returning a query of the correct type, we
are checking with the typescript row type. We should be checking with
the spacetime type, since this type checking will allow a couple
incorrect things to be returned:
1. A different table with any superset of the fields (for example, a
different table that has one extra field). That will fail when
executing, but will be allowed by the typescript compiler.
2. A table with the same fields, but with those fields in a different
order would also fail at runtime, but be allowed by the typescript
compiler.
4. A table with fields of a different spacetimetype that map to the same
typescript type (like `u16` and `u32`).
I can also add back functions for things like inequality once we are ok
with the rest of it.
# API and ABI breaking changes
This adds some new API surface, but does not break existing code.
# Expected complexity level and risk
2.
# Testing
For automated tests, there are unit tests to see what sql gets emitted
in `tests/query.test.ts`, and some tests of the types in
`view.test-d.ts`.
I've also run some manual tests with a typescript module with views.
# Description of Changes
Fixes https://github.com/clockworklabs/SpacetimeDB/issues/3729
I genuinely don't know what came over me.
# API and ABI breaking changes
None
# Expected complexity level and risk
1.5 very straightforward but not strictly trivial
# Testing
Adds automated integration tests (written in Rust and run with `cargo
test`, although note this comment from @matklad about integration tests
for the future
https://internals.rust-lang.org/t/running-test-crates-in-parallel/15639/2):
- [x] Can publish an updated module if no migration is required
- [x] Can publish an updated module if auto-migration is required (with
the yes-break flag true/false)
- [x] Cannot publish if a manual migration is required
- [x] Can publish if a manual migration is required but the user
specified `--delete-data`
- [x] Can publish if a manual migration is required by the user
specified `--delete-data=on-conflict`
- [x] No data deletion occurs if no migration is required and
`--delete-data=on-conflict` is specified
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
This implements (a subset of) the TextEncoder/TextDecoder web APIs using
native functions to do the actual `Uint8Array <-> String` conversion.
This should be a good bit faster than the `fast-text-encoding` package.
# Expected complexity level and risk
2 - this introduces new kinds of JS code and host calls to the v8 host,
but they're pretty well encapsulated.
# Testing
- [x] All TS modules make use of these already for encoding/decoding
strings in BSATN - the `fast-text-encoding` polyfill we pull in only
takes effect if the classes don't already exist, so the smoketests
passing means it works.
# Description of Changes
This showed up in flamegraphs, in particular for `Update`, so let's
cache the `SubscriptionMetrics`s.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Covered by existing tests.
# Description of Changes
Patch contain few different things, required to run query builder end to
end.
Git history seems messed up but it can be reviewed commitwise from -
69c1907b3e.
1. Decouples generic type `T` from table name, as type represents the
`struct` and not table, and there couple be multiple tables implemented
from same struct.
2. modify table macro implementaiton to generate code supporting
`traits` and types required for query builder,
3. Disable aliasing in sql queries for now, as it was causing
semantically wrong query when we were doing joins on `FromWhere` (as
original `Expr` were referencing to original table names).
4. smoketests.
# API and ABI breaking changes
Add `Query<T>` type as Views return type.
# Expected complexity level and risk
2, changes are simple but not splitted up well.
# Testing
1. Added smoketest.
TODO:
ui test.
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
As discussed; could possibly improve performance/in general it's good to
keep up with patches, it's been over a year since we last bumped this.
# Expected complexity level and risk
2 - large, important dependency but wasmtime is very solid,
well-engineered software.
# Testing
- [x] smoketests run on wasmtime
# Description of Changes
Updates the rust module bindings to use new view abi
(`ViewResultHeader`) and updates the return codes for the
`__call_view__` and `__call_view_anon__` module exports. This is in
preparation for `Query` builder support.
# API and ABI breaking changes
Not breaking. Existing modules will continue to use the old abi. New
modules will use the new abi. However previous host versions will not
support modules built using this version of the bindings.
# Expected complexity level and risk
2
# Testing
This is an internal refactor. All existing tests should continue to
pass. The only tests that needed updating were the negative module
compilation tests because the error messages produced by rustc changed.
# Description of Changes
Implements a query builder for rust modules according to the
[spec](https://github.com/clockworklabs/SpacetimeDBPrivate/blob/master/proposals/0030-views.md#5-query-builder-for-incremental-evaluation).
Look at the tests in `query_builder.rs`.
TODO: Extend return type for views to include `Query` and update the
`#[table]` macro to generate query builder bindings.
# API and ABI breaking changes
This is an additive change. Current modules do not need to be updated
unless they wish to use the query builder.
# Expected complexity level and risk
1.5, Will appreciate comments to better structure code.
# Testing
[x]: unit tests.
I have also done type safety checks manually from module.
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
This adds some changes for how we return data from view functions.
Originally, we interpreted the output of a view function as a bsatn
encoding of an array of rows. Since we also want to be able to return
queries from view functions, we need to be able to return different
types too. At this point, this is effectively not a functional change,
since we don't use the new format, and we don't actually try to parse
the new format.
This introduces a new format for view returns, which is a
`ViewResultHeader`, potentially followed by additional data. For
example, if a view were returning rows directly, it would write a
`ViewResultHeader::RowData`, followed by an array of rows. Note that we
could have given that object a byte array with the rows instead of using
a header an a separate object, but that would force us create an extra
copy when encoding and when decoding.
To make this backward compatible with existing views, we have a
different way to return the new format. For v8 views, if they return a
byte array, we assume it is the old format. If they return an object, we
expect the `data` field of that object to be the actual return data.
For wasm views, we interpret a return code of 2 to mean that it uses the
new format.
On the host side, we handle this naively: we will perform the query, and
we will act as though the view has a read dependency on the tables in
the query. In follow up PRs we can make this more efficient.
# API and ABI breaking changes
This is not a breaking change, but it does make the ABI more complicated
(specifically to avoid breaking it).
# Expected complexity level and risk
1.5. This should not affect the existing return style.
# Testing
I've done manual testing of this with a version of the typescript
bindings that returns queries.
# Description of Changes
Closes: #3781
- Added and tested procedure docs for Unreal C++ & Unreal Blueprint
- Fixed a small issue with the blueprint accessors for the event status
- Fixed a bug in the C# procedure docs
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
I built a new local test framework to do another clean end to end test
of procedures with Unreal to properly test the Blueprint work as well.
- [x] Built the Rust server alongside a new Unreal client and tested
each procedure/callback in C++ and Blueprint
- [x] Reviewed the docs locally
# Description of Changes
Bumping versions to 1.11.0 in preparation for an upcoming release.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Existing CI passes
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
NextJS 15 and 16 do not build without these development exports removed
tho they funnily enough have different errors.
<img width="961" height="262" alt="image"
src="https://github.com/user-attachments/assets/1e7ad634-d68f-4af3-a07e-302d252b41e5"
/>
Upon removing the development export everything works like a charm.
I couldn't find any benefit of having them but maybe @cloutiertyler
knows more why those are there in the first place🤷
This can be reproduced if you clone this repo i set up:
https://github.com/kistz/spacetime-next-react-hooks
Since its a build error it shouldnt matter if you have the actual module
running somewhere.
Step 1: `bun install`
Step 2: `bun dev`
Step 3: observe that the error above is appearing (not good)
Step 3: Go into `node_modules/spacetimedb/package.json`
Step 4: Remove the `development` fields under exports like in this pr
Step 5: `bun dev`
Step 6: Profit. (should only be a connection error (aka nothing renders)
at this point since the module your trying to connect to is missing)
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Not a whole lot since i dont fully grasp the impact of this change but
without it i cant even use the `spacetimedb` package with NextJS and
removing them fixes it.
But even development scenarios are working just fine without it.
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
# Description of Changes
- Update docs nav height to 56px
## Screenshots:
<img width="1256" height="55" alt="image"
src="https://github.com/user-attachments/assets/df070fb2-f3c8-4f17-ae58-6a6aa72c8033"
/>
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- maybe a test you want to do -->
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
# Description of Changes
Small cleanup of duplicate logic on smoke tests
# Expected complexity level and risk
1
# Testing
- [x] Run smoke tests
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
C# Views - Use Name from ViewAttribute instead of Method Name
# Description of Changes
The [documentation for C#
views](https://spacetimedb.com/docs/modules/c-sharp#views) says that
"Views must be declared as Public, **with an explicit Name**, and
[...]". However, the `Name` provided to the `View` attribute is not
being used as the name of the view in the Module or the generated C#
client SDK code. The `ViewDeclaration` actually checks that the `View`
attribute's name is not null or empty, but then proceeds to do nothing
with it.
This PR updates the `ViewDeclaration` to use the `Name` property from
`ViewAttribute`.
For more info - see my bug report in Discord:
https://discord.com/channels/1037340874172014652/1443881580602069043
# API and ABI breaking changes
No breaking change to the API. Though, anyone who has a view name
declared that's different from their method name will have to deal with
that during migration of their modules.
# Expected complexity level and risk
1 - Trivial change
# Testing
I compiled the C# projects under `crates/bindings-csharp`, built the
NuGet packages, and tested them locally with a project using SpacetimeDB
1.10 (CLI and associated packages).
I confirmed that the generated classes now use the value from the `View`
attribute as the `RemoteTableName`. See attached image.
<img width="1429" height="372" alt="Screenshot 2025-11-28 at 3 04 48 PM"
src="https://github.com/user-attachments/assets/1db83c14-b0dc-4bcb-87ac-50e104f4d501"
/>
---------
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
This removes all usages of `pathname:///` and replaces them with
`https://spacetimedb.com/`. `pathname:///` was resolving to `/docs` in
some cases and was not verified by our link checker. Note that this
means these links will NOT work in staging.
This is a temporary fix. We should find a way to be able to link out to
the rest of the site without hardcoding the hostname in the future.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- I tested that the links work locally (but obviously they link to the
production site).
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
The trait has already been implemented for ReducerContext and TxContext,
but implementation for AnonymousViewContext and ViewContext is still
missing.
## Background why I need this change
In SpacetimeDSL, I currently have the ReducerContext hard-coded as a
prerequisite for creating a DSL instance (see
https://github.com/tamaro-skaljic/SpacetimeDSL/blob/main/src/lib.rs#L9-L33)
.
With the addition of
- ViewContext,
- AnonymousViewContext,
- ProcedureContext, and
- TxContext,
I am now faced with the dilemma that I also have to support SpacetimeDSL
with the other contexts.
I hope to be able to use `spacetimedb::DbContext<DbView =
spacetimedb::Local>` and `spacetimedb::DbContext<DbView =
spacetimedb::LocalReadOnly>` as a common denominator.
(I signed the CLA)
# API and ABI breaking changes
No
# Expected complexity level and risk
1
Signed-off-by: Tamaro Skaljic <49238587+tamaro-skaljic@users.noreply.github.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
Moves a reducer call to inside an `on_insert` callback to avoid race
condition.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
Fixes a test
# Description of Changes
Applies the same implicit filter for views to delta tables that we
already did for physical tables.
Removes a single condition `scan.delta.is_none()` from the already
existing rewrite rule.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
- [x] Rust sdk test
# Description of Changes
In the `call_reducer_with_tx` function we only reported the WASM fuel
used by view evaulation, but not the stats from the actual reducer call.
This PR fixes it and we now properly record it.
# Expected complexity level and risk
1
# Testing
I've tested the change locally. Before the change the reported metrics
were always zero after running any reducer. Now the usage is reported
properly.
# Description of Changes
In the spirit of our planned move to concept-based documentation rather
than language-based documentation,
I've chosen to add a quick section to the overview, and then a new page
for documentation about procedures. I have not updated any tutorials or
reference pages.
# API and ABI breaking changes
N/a - docs
# Expected complexity level and risk
1 - docs
# Testing
None.
---------
Co-authored-by: Noa <coolreader18@gmail.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
I got these errors when I tried sending out the typescript NPM package:
```
cjs (brotli)
Package size limit has exceeded by 165 B
Size limit: 26 kB
Size: 26.16 kB brotlied
esm (brotli)
Size limit: 26 kB
Size: 25.87 kB brotlied
esm (gzip)
Package size limit has exceeded by 536 B
Size limit: 30 kB
Size: 30.54 kB gzipped
esm (uncompressed)
Package size limit has exceeded by 3.77 kB
Size limit: 160 kB
Size: 163.77 kB
esm min (brotli)
Package size limit has exceeded by 194 B
Size limit: 14 kB
Size: 14.19 kB brotlied
esm min (gzip)
Package size limit has exceeded by 144 B
Size limit: 16 kB
Size: 16.14 kB gzipped
esm min (uncompressed)
Package size limit has exceeded by 1.29 kB
Size limit: 65 kB
Size: 66.29 kB
```
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] After this change I was able to publish the typescript NPM
package.
Phoebe Goldman