mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-12 10:48:19 -04:00
mamcx/sql-array-render
319 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 John Detter
|
eb5000895d |
Bump versions to 1.11.1 (#3901)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> - Bump version numbers to `1.11.1` # 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 <!-- 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 - [x] Verified that the license has been updated - [x] `spacetime --version` on this commit is correct There is also a corresponding private PR. |
||
|
Zeke Foppa
|
70628fb51e |
cargo ci on windows (#3859)
# Description of Changes Make `cargo ci` work properly on Windows, in preparation for https://github.com/clockworklabs/SpacetimeDB/pull/3702. # API and ABI breaking changes No. CI-only. # Expected complexity level and risk 2. Not trivial, but not complicated. # Testing - [x] CI output seems to be genuinely running the tests, and it's passing on Windows - [x] Make a change to `crates/bindings-csharp` and see that `cargo ci test` fails - [x] I can manually run a minimal `cargo ci smoketests` invocation on a Windows machine --------- Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com> Co-authored-by: Kasama <robertoaall@gmail.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Mazdak Farrokhzad
|
907d67ec1f |
wasmtime: pool async stack allocations on unix (#3830)
# 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. |
||
|
Roberto Pommella Alegro
|
5ac65739e5 |
add initial cargo ci (#3409)
# 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> |
||
|
Kim Altintop
|
062649c92e |
client-api: Send WebSocket messages fragmented (#2931)
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. |
||
|
Noa
|
af5b04e949 |
Implement sourcemap handling (#3828)
# 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 |
||
|
Tyler Cloutier
|
46f3e07dfc |
Fixes issues with --delete-data=on-conflict (#3730)
# 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> |
||
|
Noa
|
653a2a1bad |
Update wasmtime to v39 (#3818)
# 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 |
||
|
Zeke Foppa
|
141048cdd8 |
Bump versions to 1.11.0 (#3808)
# 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> |
||
|
John Detter
|
0590f7022d |
Upgrade to version 1.10.0 (#3769)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> This upgrades the SpacetimeDB version to 1.10.0. # 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 <!-- 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 This is just a version bump - not tested. |
||
|
joshua-spacetime
|
0a3dda7f4e |
Add rust sdk tests for views (#3755)
# Description of Changes Rust SDK test suite for views # API and ABI breaking changes None # Expected complexity level and risk 1 # Testing This patch only adds tests, it does not change functionality. |
||
|
Mazdak Farrokhzad
|
ed2a18cff7 |
Bump hashbrown, foldhash; Fix some compile errors in master (#3722)
# Description of Changes There were mentions of `hashbrown` in the repo that did not go through `spacetimedb_data_structures::map`. This caused compile errors on master when running certain tests locally. These have been replaced with the proper imports. The PR also bump hashbrown to 0.16.1 and foldhash to 0.2.0. # API and ABI breaking changes None # Expected complexity level and risk 2 # Testing Covered by existing tests. |
||
|
John Detter
|
77886a50a9 |
Upgrade to version 1.9.0 (#3709)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> Upgrade to version 1.9.0. # API and ABI breaking changes None - just a version upgrade. <!-- 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] I verified that the license has been updated - [x] The version number looks correct (1.9.0) --------- Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Noa
|
de142d4af9 |
HTTP followup: remove http dep from spacetimedb_lib (#3719)
# Description of Changes Follow up to #3684. Moves `Error` and `Timeout` out of lib, so that we don't have to implement `SpacetimeType` for them, and then removes the http dependency altogether, so that `lib` can be leaner. I also got rid of the separate `HttpValue` type, since it only really exists to mirror the `http` crate and typescript won't make use of it. # Expected complexity level and risk 1 # Testing n/a - just code movement. |
||
|
Phoebe Goldman
|
7df8719b61 |
Add procedure HTTP request API for WASM modules and the Rust module bindings library (#3684)
# Description of Changes Closes #3517 . With this PR, procedures (at least, those defined in Rust modules) can perform HTTP requests! This is performed through a new field on the `ProcedureContext`, `http: HttpClient`, which has a method `send` for sending an `http::Request`, as well as a convenience wrapper `get`. Internally, these methods hit the `procedure_http_request` ABI call / host function, which uses reqwest to perform an HTTP request. The request is run with a user-configurable timeout which defaults and is clamped to 500 ms. Rather than exposing the HTTP stream to modules, we download the entire response body immediately, within the same timeout. I've added an example usage of `get` to `module-test` which performs a request against `localhost:3000` to read its own schema/moduledef. This PR also makes all procedure-related definitions in the Rust module bindings library `#[cfg(feature = "unstable")]`, as per #3644 . The rename of the `/v1/database/:name/procedure/:name` route is not included in this PR, so this does not close #3644 . Left as TODOs are: - Metrics for recording request and response size. - Improving performance by stashing a long-lived `reqwest::Client` someplace. Currently we build a new `Client` for each request. - Improving performance (possibly) by passing the request-future to the global tokio executor rather than running it on the single-threaded database executor. # API and ABI breaking changes Adds new APIs, which are marked as unstable. Adds a new ABI, which is not unstable in any meaningful way (we can't really do that). Marks unreleased APIs as unstable. Does not affect any pre-existing already-released APIs or ABIs. # Expected complexity level and risk 3 or so: networking is scary, and even though we impose a timeout which prevents these connections from being truly long-lived, they're still potentially long-lived on the scale of Tokio futures. It's possible that running them on the database core is problematic in some way, and so what I've left as a performance TODO could actually be a concurrency-correctness issue. # Testing - [x] Manually wrote and executed some procedures which make HTTP requests. - [x] Added two automated tests to the `sdk-test` suite, `procedure::http_ok` and `procedure::http_err`, which make successful and failing requests respectively, then return its result. A client then makes some assertions about the result. --------- Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
Tyler Cloutier
|
ce543854e9 |
Unifies server module library and client SDK for TypeScript (and fixes several bugs) (#3559)
# Description of Changes This PR is a very large change to the workings of the TypeScript SDK and as such requires a higher bar of testing than other PRs. However, it does several important things: 1. Unifies the API of the server and client so they not only have the same API, but they actually implement it with the same TypeScript types. This fixes several inconsistencies between them and fixes several small bugs as well. 2. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3365 3. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3431 4. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3435 5. Subsumes the work done in https://github.com/clockworklabs/SpacetimeDB/pull/3447 6. Derives all type information on the client from a single `RemoteModule` type which vastly cleans up the correctness of type checking on the client and helped me to find several small bugs It accomplishes this by changing code generation of TypeScript on the client to code generation approximately what a developer would manually write in their module. The ultimate goal would be to allow the developer to use the types and functions that they define on in their module directly on the client without needing to do any code generation at all, provided they are using TypeScript on the server and client. https://github.com/clockworklabs/SpacetimeDB/issues/3365 is resolved by `.build()`ing the `DbConnection` inside a React `useEffect` rather than doing it directly in line with the render of the provider. In order to do that we needed to not expose the `DbConnection` directly to developers by returning a different type from `useSpacetimeDB`. `useSpacetimeDB` now returns a `ConnectionState` object which is stored as React state and updates when any of the fields change. This change also resolves https://github.com/clockworklabs/SpacetimeDB/issues/3431. https://github.com/clockworklabs/SpacetimeDB/issues/3435 was the issue that initially lead me down the rabbit hole of unifying the server and the client because it was nearly impossible to track down all the various type functions and how they connect to the values that we code generate on the server. After several hours of attempting this, I decided to clean up the types a bit to be more uniform. Implementing the unification between the client and the server also necessitated fully implemented parts of the API that were fully implemented on the server, but were broken or missing on the client. # API and ABI breaking changes [Unification] -> Means that this is breaking behavior for the client SDK, but that the new behavior is identical to the server's existing behavior ## Breaking changes: - Table accessor names and index accessor names are converted to camelCase on the `ctx`, so `ctx.db.foo_bar` is now `ctx.db.fooBar` - [Unification] On the client `my_table.iter()` returns `IterableIterator` instead of an `Array` - [Unification] `module_bindings` now export `TypeBuilder`s for all types instead of a `type MyType` and object `MyType`, so instead of using `MyType` as a type directly, you need to infer the type `MyType` -> `Infer<typeof MyType>`. - [Unification] We no longer generate and export `MyTypeVariants` for sum types (these are now accessed by `Infer<typeof MyType.variants.myVariant>`) - [Unification] `MyType.getTypeScriptAlgebraicType()` has been replaced with `MyType.algebraicType` - `useSpacetimeDB()` no longer takes type parameters - `useTable()` now takes a `TableDef` parameter and type params are inferred - `useTable()` now just returns an `Array` directly instead of a object with `{ rows }` - [Unification] `ctx.reducers.createPlayer(argA, argB)` -> `ctx.reducers.createPlayer({ argA, argB })` - [Unification] `ctx.reducers.onCreatePlayer(ctx, argA, argB)` -> `ctx.reducers.onCreatePlayer(ctx, { argA, argB })` - [Unification] `ctx.reducers.removeOnCreatePlayer(ctx, argA, argB)` -> `ctx.reducers.removeOnCreatePlayer(ctx, { argA, argB })` - [Unification] `myTable.count(): number` -> `myTable.count(): bigint` ## Additive changes: - `Infer<>` now also does `InferTypeOfRow<>` if applicable - Added a `useReducer()` React hook - `module_bindings` now exports a `tables` object with references to all the `TableDef`s - `module_bindings` now exports a `reducers` object with references to all the `ReducerDef`s - Added a new `MyType.create('MyVariant', ...)` function in addition to the `MyType.MyVariant(...)` constructors (this is private) ## Notable things that did not change: - `MyType.serialize(writer: BinaryWriter, value: Infer<typeof MyType>)` and `MyType.deserialize(reader: BinaryReader): Infer<typeof MyType>` are still supported exactly as before. - The `MyType.MyVariant(...)` constructor function on sum types is still present, but implemented with the private `MyType.create('MyVariant', ...)`. We could choose to move away from this API later if we didn't like the variants polluting the namespace # Expected complexity level and risk 4 - This is a deep reaching an complex change for the SDK. For the server, it is much less deep reaching since it reuses much of the same machinery, although it does require thorough testing there as some of the code was modified. This change is fully localized to TypeScript and does not touch the host (or other languages) at all, and therefore only impacts a beta aspect of SpacetimeDB. # 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! --> - [ ] Added regression test for https://github.com/clockworklabs/SpacetimeDB/issues/3435 - [x] Manually tested `test-app` and `test-react-router-app` - [ ] Add test cases for camelCase-ing --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
Mazdak Farrokhzad
|
31a8d5f154 |
Remove the middle man thread the JS worker thread (#3577)
# Description of Changes This makes us go from 3 threads to 2. The next step is to core pin the V8 worker thread. # API and ABI breaking changes None # Expected complexity level and risk 4 # Testing Existing tests should cover this. --------- Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
John Detter
|
6bd557254d |
Upgrade to version 1.8.0 (#3633)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> - This upgrades the versions of all SDKs, the CLI, etc. to 1.8.0 # 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 <!-- 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. --> 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! --> - [x] I verified that all versions seem to be updated including the BSL license update <!-- maybe a test you want to do --> We have 1 `1.7.0` that didn't get upgraded automatically because it is part of the module bindings for a template: ``` crates/cli/.templates/parent_parent_crates_bindings-typescript_examples_quickstart-chat/src/module_bindings/index.ts: cliVersion: '1.7.0', ``` A case could possibly be made for bumping the template but it shouldn't cause any issues as the module bindings directory should just get regenerated by the user. @cloutiertyler should we be bumping module bindings for templates when we upgrade versions? --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com> |
||
|
Kim Altintop
|
a36f7091d5 |
[teams 3/5] API authorization, CLI, smoketests (#3523)
This adds authorization to the relevant API endpoints, updates the CLI commands and adds smoketests for the teams feature. **Note**: Authorizing SQL (incl. subscriptions) is a bit more involved, and submitted as a separate PR in the series. Depends-on: https://github.com/clockworklabs/SpacetimeDB/pull/3519 |
||
|
Kim Altintop
|
e0b8e6f265 |
[teams 1/5] Reset database (#3611)
So far, the `--clear-database` option to `publish` has simply dropped and then re-created the database (if it did exist). This will no longer work when databases can have "children": because dropping and re-creating is not atomic, children would either become orphans, or be dropped as well. To solve this, `reset_database` is introduced as a separate action that: - shuts down all replicas - if a `program_bytes` is supplied, replaces the database's initial program - if a `host_type` is supplied, replaces the database's host type - starts `num_replicas` or the previous number of replicas, which initialize themselves as normal As this could be its own CLI command, the action is provided as its own API endpoint (undocumented). However, since `publish` has no way of knowing whether the database it operates on actually exists, the `publish_database` handler will just invoke the `reset_database` handler if `clear=true` and the database exists, and return its result. This is to avoid starting the transfer of the program in the request body, only to receive a redirect. Some refactoring was necessary to dissect and understand the flow. # API and ABI breaking changes Introduces a new, undocumented API endpoint. We may want to nest it under `/unstable`. # Expected complexity level and risk 2 # Testing From the outside, the observed behavior should be as before, so smoketests should cover it. |
||
|
Phoebe Goldman
|
565e95bdf4 |
Add Rust client SDK bindings for calling procedures (#3532)
# Description of Changes This commit adds support to the Rust client SDK for calling procedures. Similar to reducers, each `DbContext` implementor has a `pub procedures: RemoteProcedures` field, with methods provided by extension traits for each procedure. Unlike reducers, the provided methods are invoke and invoke-then. Invoke-then takes a `FnOnce` callback to run when the SDK is notified of the procedure's termination status, while invoke ignores that notification. No mechanism is provided for observing procedures invoked by other clients. Procedure callbacks are implemented by storing a map from `request_id` to `ProcedureCallback`, with the callback closure internally knowing how to deserialize the return value. It's mildly unfortunate to deserialize within the callback instead of on the preprocess background task, but it saves significant complexity. This commit also adds a new sdk-test module, `sdk-test-procedures`, and a new Rust test client, `procedure-client`. Together, these are used in two tests of invoking and observing procedures. I've left TODOs for other tests that we should write as we implement additional procedure features. I also had to fix a few minor bugs in the Rust codegen which were not strictly related to procedures: we previously assumed that the sets of reducers and of tables were non-empty, which led to wonky invalid codegen on modules which did not define any reducers or which did not define any tables. I'm sneaking a change to the Nix flake into this PR as well - when initially writing it I had included `cargoArtifacts` (the pre-built and cached dependencies of our actual builds) in its `packages`, but that was neither necessary or useful, and just made building the shell take a long time after dependency changes. # API and ABI breaking changes Breaks the internal interface between the Rust client SDK and codegen, so users will have to re-run `spacetime generate`. # Expected complexity level and risk 2-ish? Pretty simple change to the Rust SDK overall. # Testing - [x] Added new automated integration tests exercising the new functionality. --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Kim Altintop
|
cfd0d4b712 |
commitlog,durability: Support preallocation of disk space (#3437)
When a new commitlog segment is created, allocate disk space for it up to the maximum segment size. Also do this when resuming writes to an existing segment, such that segments created without preallocation will allocate as well when the database is opened. Preallocation is gated behind the feature "fallocate", because it is not always desirable to preallocate, e.g. for local `standalone` users. The feature can only be enabled on Linux targets, because allocation is done using the Linux-specific `fallocate(2)` system call. Unlike `ftruncate(2)` or the portable `posix_fallocate(3)`, `fallocate(2)` supports allocating disk space without zeroing. This is currently required, because the commitlog format does not handle padding bytes. If not enough space can be allocated, the commitlog refuses writes. For commitlogs that were created without preallocation, this means that the commitlog cannot even be opened in this situation. The local durability impl will crash if it detects that the commitlog is unable to allocate enough space. This means that a database will eventually crash and be unable to start in an out-of-space situation. Allocated space is not included in the reported size of the commitlog. Instead, allocated blocks are reported separately. # Expected complexity level and risk 3 - Disk size monitoring may need to be adjusted. # Testing - [x] Adds a test that demonstrates the crash behavior of [`spacetimedb_durability::Local`] when there is insufficient space. The test performs I/O against a loop device. - [x] Modified the `repo::Memory` impl so that it can run out of space. No test currently utilizes this, but existing tests assuming infinite space still pass. |
||
|
Shubham Mishra
|
75c6e67c3c |
Views: Host interface for WASM modules (#3548)
# Description of Changes Host implementation to invoke `call_view` method. I also covers: 1. API `MutTxId::is_materialized`to check if existing view exisits and updated. 2. Update in readsets logic to remove stale views. 3. sql caller implmentation. # API and ABI breaking changes NA 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. 3 |
||
|
Zeke Foppa
|
09828ee954 |
Revert "[teams 1/5] Reset database (#3496)" (#3580)
# Description of Changes This reverts commit #3496. # API and ABI breaking changes Technically maybe yes? But definitely nothing is using the new code yet. # Expected complexity level and risk 1 # Testing CI only Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Kim Altintop
|
5c42b091aa |
[teams 1/5] Reset database (#3496)
So far, the `--clear-database` option to `publish` has simply dropped and then re-created the database (if it did exist). This will no longer work when databases can have "children": because dropping and re-creating is not atomic, children would either become orphans, or be dropped as well. To solve this, `reset_database` is introduced as a separate action that: - shuts down all replicas - if a `program_bytes` is supplied, replaces the database's initial program - if a `host_type` is supplied, replaces the database's host type - starts `num_replicas` or the previous number of replicas, which initialize themselves as normal As this could be its own CLI command, the action is provided as its own API endpoint (undocumented). However, since `publish` has no way of knowing whether the database it operates on actually exists, the `publish_database` handler will just invoke the `reset_database` handler if `clear=true` and the database exists, and return its result. This is to avoid starting the transfer of the program in the request body, only to receive a redirect. Some refactoring was necessary to dissect and understand the flow. # API and ABI breaking changes Introduces a new, undocumented API endpoint. We may want to nest it under `/unstable`. # Expected complexity level and risk 2 # Testing From the outside, the observed behavior should be as before, so smoketests should cover it. |
||
|
Zeke Foppa
|
34b4a2b899 |
Bump versions to 1.7.0 (#3550)
# Description of Changes Bump versions to 1.7.0 in preparation for the release. # 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 1 # Testing - [x] CI passes --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Piotr Sarnacki
|
b2cee93b52 |
New command: spacetime dev (#3469)
# Description of Changes This PR implements a new command for the CLI: `spacetime dev`. If run from outside of a project directory, it will call `init` in interactive mode to allow user to create a project. If run from a project directory, it will ask for a module to conect to and it will: * subscribe to logs * observe files in the `spacetimedb` directory and automatically publish to SpacetimeDB One caveat is that instead of reusing the `logs` code I did some repetition cause currently the logs code acquires a lock that lives through await points. It is fixable, but due to limited time I decided to go with a bit of code duplication. It shouldn't be very hard to fix later, though. --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com> Co-authored-by: = <cloutiertyler@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
Piotr Sarnacki
|
647be7e9c0 |
spacetime init rewrite (#3366)
This is a draft of the new functionality for `spacetime init`. In order to run it with built-in templates you have to set the path to the config file: ``` export SPACETIMEDB_CLI_TEMPLATES_FILE=crates/cli/.init-templates.json ``` In the future it will fetch the list from GH. A few notes: * the previous functionality of `spacetime init` does not work at the moment * the code needs a bit more cleanup and tests before merging * there is a bit of a mix in how we generate empty server and client projects. For Rust we use the existing way of generating. For TypeScript we clone an empty project from the repo. I wanted to play with both ways of doing things, and I'm still not sure which is better. Generation in Rust means that the generated code will match the CLI version and not necessarily whatever is in Git. On the other hand, for the builtin templates we will be fetching the newest version from GH, which I guess might also not what we want, ie. we probably want only stable templates. More discussion is needed here * we use `spacetimedb` directory for the server files * I don't particularly like the inability to disable interactive mode easily. We discussed disabling it by default if all of the required arguments are passed, but I don't think it's feature proof. For example, if someone relies on a non-interactive mode, and we add a new required argument, instead of printing a message `missing --foo`, we will automatically launch interactive mode, which is harder to debug. That's why I think I'd prefer to implement `--non-interactive` argument * it's kind of hard to keep the legacy behaviour. If you don't pass any arguments, we go into interactive mode. In the legacy version, we would print required arguments. If someone passes `--lang` or `--project-path` explicitly, I guess we could run the legacy workflow, but not sure if it's worth it, as the command was marked as unstable anyway * the project path defaults to the project name, but I think we should probably replace change whitespaces to dashes, or at least ask for the project path with the project name being the default (or both) --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com> Co-authored-by: = <cloutiertyler@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
Noa
|
ddfdde2b0f |
Update to pgwire 0.34.2 (#3451)
# Description of Changes This is primarily to get their fixes for the tls negotiation deadloop that we were experiencing. [This is the diff](https://github.com/sunng87/pgwire/compare/v0.32.1...v0.34.1) of changes between 0.32.1 and 0.34.1. # 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 2? This was something we discussed wanting to do. It's a change to an important dependency, but we know it comes with stuff we want. # 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! --> n/a - problem not in this repo. - [ ] <!-- 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. --> |
||
|
Ning Sun
|
d205795553 |
feat: update pgwire to 0.34 and improve how we disable ssl (#3432)
# Description of Changes Hello team, I'm the original author of pgwire library. In this patch, I have some updates about spacetimedb's usage of pgwire library: - Updated pgwire library to 0.34, which includes a critical fix for busy loop on accepting new connection - This version will return error on no-op handlers, as requested by @mamcx - Update `StartupHandler` for `SslRequest`. `SslRequest` is handled in `process_socket` automatically before `StartupHandler` kicks in. So it's safe to remove the match branch. The framework will reject TLS negotiation automatically if no TLS support compiled - Updated feature flags. Add `no-default-features` so we will not pull TLS dependencies. # API and ABI breaking changes N/A # Expected complexity level and risk 1 # Testing Would be nice to verify if you have integration test on postgres interface. --------- Co-authored-by: Mario Montoya <mamcx@elmalabarista.com> |
||
|
Tyler Cloutier
|
3309404c1b |
Fixed the react router issue and added a new test app to test for it (#3428)
# Description of Changes This PR fixes https://github.com/clockworklabs/SpacetimeDB/issues/3359. Additionally I have add a new test app to test for this issue and I changed a perl script to be portable on windows. The issue was that `useTable` had it's own `isActive` state that it was incorrectly maintaining, when it should just have been using the connections `isActive` state directly. This fixes a critical bug and should be pushed ASAP. # API and ABI breaking changes None, fixes a critical bug. # Expected complexity level and risk 2, quite straightforward fix after figuring it out. # Testing - [x] I added a test app and tested the fix in my browser. --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Jeffrey Dallatezza
|
dbc49b1fd6 |
Add AuthCtx to ReducerContext for rust (#3288)
# Description of Changes This exposes client credentials in reducer calls for rust. # API and ABI breaking changes API Changes: The main API change is the addition of `AuthCtx` and the `sender_auth` in `ReducerContext`. This also adds JwtClaims, which has some helpers for getting commonly used claims. ABI Changes: This adds one new functions `get_jwt`. This uses `st_connection_credentials` to look up the credentials associated with a connection id. This adds ABI version 10.2. # Expected complexity level and risk 2. This adds new ABI functions # Testing I've done some manual testing with modified versions of the quickstart. We should add some examples that use the new API. |
||
|
Phoebe Goldman
|
0a6aa7c5d9 |
ModuleDef and schema changes to support procedures (#3392)
# Description of Changes This commit extends various schema and schema-adjacent structures to describe procedures, a new kind of database function which are allowed to perform side effects. This includes extending `RawModuleDefV9` with a way to register `RawProcedureDefV9`s in the `misc_exports`, preserving compatibility with modules that predate procedures. The module validation path is reorganized somewhat to validate various properties related to procedures while preserving code clarity and maintainability. Additionally, the `ArgsTuple` machinery for ser/de-ing reducer arguments using the argument type as a seed is extended to also support procedure arguments. All of this is currently unused. # API and ABI breaking changes Additive and backwards-compatible additions to `RawModuleDefV9` and friends. # Expected complexity level and risk 2 - some minor complexity in schema validation which may have gotten borked in a merge at some point. # Testing Unsure what tests would be useful, open to suggestions from reviewers. - [ ] <!-- 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. --> |
||
|
Noa
|
bb43213245 |
Typescript module API (#3327)
# Description of Changes Currently based on #3361 Implements most of the TS module API (not yet a function for type aliases). # 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! --> - [x] Extremely basic module stuff works - [ ] <!-- maybe a test you want a reviewer to do, so they can check it off when they're satisfied. --> --------- Signed-off-by: Noa <coolreader18@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com> Co-authored-by: = <cloutiertyler@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Zeke Foppa
|
d4837c37ab |
Bump versions to 1.6.0 (#3413)
# Description of Changes Bumping versions to 1.6.0 in preparation for upcoming release. # API and ABI breaking changes None # Expected complexity level and risk 1 # Testing - [x] Existing CI only --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Zeke Foppa
|
544e2edc2d |
Pin temporal_rs version (#3385)
# Description of Changes Pin the `temporal_rs` and `timezone_provider` versions to `0.0.11`, because future versions such as `0.0.16` are incompatible, but their version constraints are not correct so we keep getting auto-rolled-forward to build-breaking versions. # API and ABI breaking changes None. # Expected complexity level and risk 1 # Testing - [x] CI passes - [x] If I `rm Cargo.lock && cargo clippy`, the build still passes Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Phoebe Goldman
|
aa295825f6 |
async-ify Wasmtime (and v8) execution (#3263)
# Description of Changes In service of adding procedures, which will need to execute WASM code in an `async` environment so as to suspend execution while making HTTP requests and whatnot. Prior to this PR, `JobCores` worked by spawning an OS thread for each database. These threads would then each be pinned to a specific core, and in multi-tenant deployments multiple threads could be pinned to the same core. Now, instead, we spawn one thread per available core at startup. Each of these threads runs a single-threaded Tokio executor. Each database is assigned to one of these executors, and runs tasks on it via `tokio::spawn`. When we run without core pinning (usually due to having too few hardware cores), we won't spawn any additional threads or Tokio runtimes at all; instead we will run database jobs on the "global" Tokio executor. These jobs may block Tokio worker threads, which might be an issue if a very core-constrained device runs multiple databases with very long-running reducers. If this is an issue, we could in this case instead build a second Tokio runtime only for running database jobs, and let the OS scheduler figure things out like it did previously. Previously, we implemented load-balancing among the database cores by occasionally instructing per-database threads to re-pin themselves. Now, we instead periodically send the database a new `wasmtime::runtime::Handle`, which they will `spawn` future jobs into. Previously, it was possible for a database thread to become canceled, most likely as a result of `ModuleHost::exit`, after which calls would fail with `NoSuchModule`. Cancellation is no longer meaningful, as the database holds a `Handle` to a long-lived `tokio::runtime::Runtime`, which should always outlive the `ModuleHost`. I have added an `AtomicBool` flag to `ModuleHost` which is flipped by `exit` and checked by calls to maintain the previous functionality. Within this PR, the jobs run on the database-execution Tokio tasks are not actually asynchronous; they will never yield. This is important because these jobs may (will) hold a transaction open, and attempting to swap execution to another job which wants a transaction on the same database would be undesirable. Note that this may regress our multi-tenant performance / fairness: previously, in multi-tenant environments, the OS scheduler would divide the database cores' time between the per-database threads, potentially causing one high-load database to be interrupted in the middle of a reducer in order to run other databases pinned to the same core. Now, a high-load database will instead run its entire reducer to completion before any other database gets to run. We could, in the future, change this by instructing Wasmtime to yield periodically, either via [epoch interruption](https://docs.wasmtime.dev/api/wasmtime/struct.Store.html#method.epoch_deadline_async_yield_and_update) or [fuel](https://docs.wasmtime.dev/api/wasmtime/struct.Store.html#method.fuel_async_yield_interval), both of which we're already configuring Wasmtime to track. We'd need (or at least want) to (re-)introduce a queue s.t. we only attempt to run one job for each database at a time. I have chosen not to do so within this patch because I felt the changeset was complex enough already, and we have so far not treated fairness in multi-tenant environments as a high priority. I have also reworked our module host machinery to no longer use dynamic dispatch and trait polymorphism to manage modules and their instances, and instead introduced `enum Module` and `enum Instance`, each of which has a variant for Wasm and another for V8. During this rewrite, I reworked `AutoReplacingModuleInstance`, which previously used type-erased trait generics in a way that was brittle and hard to re-use in the new `async` context. (Specifically, the module instance no longer lives on the job thread, rather, the database grabs the instance and sends it to the job thread, then gets it back when the job exits. This is necessary to allow the re-worked load balancing described above, as we can't have a single long-lived async task.) While refactoring, I replaced it with `ModuleInstanceManager`, which can now maintain multiple instances of the same module. This is not yet useful, but will become necessary with procedures, as each concurrent procedure will need its own instance. Relatedly, I changed `ModuleHost::on_module_thread` (used by one-off and initial subscription queries) to no longer acquire the/an instance. I discussed this with the team, and consensus was that "locking" the module instance in that path was not a useful behavior, just an artifact of the previous implementation. I have also switched our Wasmtime configuration to set `async_support(true)`. This causes a variety of methods, notably `InstancePre::instantiate` and `TypedFunc::call`, to panic, and requires that we instead call their `_async` variants. As mentioned above, I have not yet introduced any actual asynchronicity or concurrency, so these methods should never yield. Rather than `.await`ing their futures, I have defined a degenerate `async` executor, `poll_once_executor`, which polls a future exactly once, failing if it does not return `Poll::Ready`. This means that we will panic if one of these futures returns `Poll::Pending` unexpectedly. The previous `trait Module` had a method `initial_instances`. `Module` is now a concrete type, and I gave it this method, but it appears to be unused. This is causing lints to fail. I am unsure what, if anything, that method was for. The previous `AutoReplacingModuleInstance` called `create_instance` on the job thread. I am unsure if this was intentional, or just an artifact of the previous implementation, where the `AutoReplacingModuleInstance` lived on the job thread. I have written the new `ModuleInstanceManager` to call `create_instance` on the calling thread, but it would be easy to move that call into the job executor if that behavior is desired. # API and ABI breaking changes None user-facing # Expected complexity level and risk 4: significant rewrite of performance-sensitive fiddly concurrency code. Note specifically in above description: - Running database jobs on the global Tokio runtime when not using core pinning. - Multi-tenant fairness issue: no longer possible to interrupt a performance-intensive database mid-reducer to run another database pinned to the same core. - Unused method `module_instances`. - Running `create_instance` on the calling thread rather than the database thread. # 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] Will arrange for a bot test. - [ ] Determine to what extent we can run with real or synthetic multi-tenant load in a test or staging environment. --------- Signed-off-by: Phoebe Goldman <phoebe@goldman-tribe.org> Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com> Co-authored-by: joshua-spacetime <josh@clockworklabs.io> |
||
|
Mazdak Farrokhzad
|
4a57de1003 |
v8: use fast static strings for known strings (#3351)
# Description of Changes v8: use fast static strings for known strings # API and ABI breaking changes None # Expected complexity level and risk 1 # Testing Covered by existing. --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Zeke Foppa
|
77a219aca6 |
Integrate tools/upgrade-version into cargo and expand (#3308)
# Description of Changes
`tools/upgrade-version` can now be run via just `cargo bump-versions`.
By default, it does nothing. You must now specify at least one of:
`--rust-and-cli`, `--typescript`, or `--csharp`.
This also now bumps the `StdbModule.csproj` version in
`demo/Blackholio`. I'm not sure if that's desired or not, but it was
still at `1.0.0` which doesn't seem quite right.
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
- [x] `cargo bump-versions 1.5.0 --rust-and-cli`
```
diff --git a/Cargo.lock b/Cargo.lock
index 941b9d66d..3800e547f 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -436,3 +436,3 @@ dependencies = [
"anyhow",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -1023,3 +1023,3 @@ dependencies = [
name = "connect_disconnect_client"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -3089,3 +3089,3 @@ dependencies = [
"log",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -3414,3 +3414,3 @@ dependencies = [
"log",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -3897,3 +3897,3 @@ dependencies = [
"log",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -4382,3 +4382,3 @@ dependencies = [
"log",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -5077,3 +5077,3 @@ dependencies = [
"paste",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -5082,3 +5082,3 @@ dependencies = [
name = "sdk-unreal-test-harness"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5456,3 +5456,3 @@ dependencies = [
"log",
- "spacetimedb 1.4.0",
+ "spacetimedb 1.5.0",
]
@@ -5479,3 +5479,3 @@ dependencies = [
name = "spacetimedb"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5488,6 +5488,6 @@ dependencies = [
"scoped-tls",
- "spacetimedb-bindings-macro 1.4.0",
- "spacetimedb-bindings-sys 1.4.0",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-bindings-macro 1.5.0",
+ "spacetimedb-bindings-sys 1.5.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
"trybuild",
@@ -5497,3 +5497,3 @@ dependencies = [
name = "spacetimedb-auth"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5504,3 +5504,3 @@ dependencies = [
"spacetimedb-jsonwebtoken",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
]
@@ -5509,3 +5509,3 @@ dependencies = [
name = "spacetimedb-bench"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5537,7 +5537,7 @@ dependencies = [
"spacetimedb-execution",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-query",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -5570,3 +5570,3 @@ dependencies = [
name = "spacetimedb-bindings-macro"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5576,3 +5576,3 @@ dependencies = [
"quote",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"syn 2.0.101",
@@ -5591,5 +5591,5 @@ dependencies = [
name = "spacetimedb-bindings-sys"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
]
@@ -5598,3 +5598,3 @@ dependencies = [
name = "spacetimedb-cli"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5634,5 +5634,5 @@ dependencies = [
"spacetimedb-jsonwebtoken",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-schema",
@@ -5659,3 +5659,3 @@ dependencies = [
name = "spacetimedb-client-api"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5696,3 +5696,3 @@ dependencies = [
"spacetimedb-jsonwebtoken",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
@@ -5713,3 +5713,3 @@ dependencies = [
name = "spacetimedb-client-api-messages"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5727,5 +5727,5 @@ dependencies = [
"smallvec",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"strum",
@@ -5736,3 +5736,3 @@ dependencies = [
name = "spacetimedb-codegen"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5745,4 +5745,4 @@ dependencies = [
"spacetimedb-data-structures",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-schema",
@@ -5753,3 +5753,3 @@ dependencies = [
name = "spacetimedb-commitlog"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5773,4 +5773,4 @@ dependencies = [
"spacetimedb-paths",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"tempfile",
@@ -5785,3 +5785,3 @@ dependencies = [
name = "spacetimedb-core"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5863,3 +5863,3 @@ dependencies = [
"spacetimedb-jwks",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-memory-usage",
@@ -5868,5 +5868,5 @@ dependencies = [
"spacetimedb-physical-plan",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-query",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -5905,3 +5905,3 @@ dependencies = [
name = "spacetimedb-data-structures"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5919,3 +5919,3 @@ dependencies = [
name = "spacetimedb-datastore"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5939,7 +5939,7 @@ dependencies = [
"spacetimedb-execution",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-metrics",
"spacetimedb-paths",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -5954,3 +5954,3 @@ dependencies = [
name = "spacetimedb-durability"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5961,3 +5961,3 @@ dependencies = [
"spacetimedb-paths",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-sats 1.5.0",
"thiserror 1.0.69",
@@ -5969,3 +5969,3 @@ dependencies = [
name = "spacetimedb-execution"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5974,6 +5974,6 @@ dependencies = [
"spacetimedb-expr",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-physical-plan",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-sql-parser",
@@ -5984,3 +5984,3 @@ dependencies = [
name = "spacetimedb-expr"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -5991,6 +5991,6 @@ dependencies = [
"pretty_assertions",
- "spacetimedb 1.4.0",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb 1.5.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -6002,3 +6002,3 @@ dependencies = [
name = "spacetimedb-fs-utils"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6064,3 +6064,3 @@ dependencies = [
name = "spacetimedb-lib"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6082,7 +6082,7 @@ dependencies = [
"serde_json",
- "spacetimedb-bindings-macro 1.4.0",
+ "spacetimedb-bindings-macro 1.5.0",
"spacetimedb-memory-usage",
"spacetimedb-metrics",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"thiserror 1.0.69",
@@ -6092,3 +6092,3 @@ dependencies = [
name = "spacetimedb-memory-usage"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6102,3 +6102,3 @@ dependencies = [
name = "spacetimedb-metrics"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6112,3 +6112,3 @@ dependencies = [
name = "spacetimedb-paths"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6128,3 +6128,3 @@ dependencies = [
name = "spacetimedb-pg"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6139,3 +6139,3 @@ dependencies = [
"spacetimedb-client-api-messages",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"thiserror 1.0.69",
@@ -6146,3 +6146,3 @@ dependencies = [
name = "spacetimedb-physical-plan"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6153,4 +6153,4 @@ dependencies = [
"spacetimedb-expr",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-schema",
@@ -6174,3 +6174,3 @@ dependencies = [
name = "spacetimedb-primitives"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6186,3 +6186,3 @@ dependencies = [
name = "spacetimedb-query"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6194,5 +6194,5 @@ dependencies = [
"spacetimedb-expr",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-physical-plan",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-sql-parser",
@@ -6229,3 +6229,3 @@ dependencies = [
name = "spacetimedb-sats"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6254,6 +6254,6 @@ dependencies = [
"smallvec",
- "spacetimedb-bindings-macro 1.4.0",
+ "spacetimedb-bindings-macro 1.5.0",
"spacetimedb-memory-usage",
"spacetimedb-metrics",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"thiserror 1.0.69",
@@ -6263,3 +6263,3 @@ dependencies = [
name = "spacetimedb-schema"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6280,5 +6280,5 @@ dependencies = [
"spacetimedb-data-structures",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-sql-parser",
@@ -6293,3 +6293,3 @@ dependencies = [
name = "spacetimedb-sdk"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6312,5 +6312,5 @@ dependencies = [
"spacetimedb-data-structures",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-metrics",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-testing",
@@ -6323,3 +6323,3 @@ dependencies = [
name = "spacetimedb-snapshot"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6340,6 +6340,6 @@ dependencies = [
"spacetimedb-fs-utils",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -6356,6 +6356,6 @@ dependencies = [
name = "spacetimedb-sql-parser"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
"derive_more",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"sqlparser",
@@ -6366,3 +6366,3 @@ dependencies = [
name = "spacetimedb-standalone"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6390,3 +6390,3 @@ dependencies = [
"spacetimedb-datastore",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
@@ -6407,3 +6407,3 @@ dependencies = [
name = "spacetimedb-subscription"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6412,5 +6412,5 @@ dependencies = [
"spacetimedb-expr",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-physical-plan",
- "spacetimedb-primitives 1.4.0",
+ "spacetimedb-primitives 1.5.0",
"spacetimedb-query",
@@ -6420,3 +6420,3 @@ dependencies = [
name = "spacetimedb-table"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6436,6 +6436,6 @@ dependencies = [
"spacetimedb-data-structures",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-memory-usage",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -6446,3 +6446,3 @@ dependencies = [
name = "spacetimedb-testing"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6462,3 +6462,3 @@ dependencies = [
"spacetimedb-data-structures",
- "spacetimedb-lib 1.4.0",
+ "spacetimedb-lib 1.5.0",
"spacetimedb-paths",
@@ -6473,3 +6473,3 @@ dependencies = [
name = "spacetimedb-update"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6498,3 +6498,3 @@ dependencies = [
name = "spacetimedb-vm"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6508,5 +6508,5 @@ dependencies = [
"spacetimedb-execution",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-primitives 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-primitives 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-schema",
@@ -6589,3 +6589,3 @@ dependencies = [
name = "sqltest"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6608,4 +6608,4 @@ dependencies = [
"spacetimedb-datastore",
- "spacetimedb-lib 1.4.0",
- "spacetimedb-sats 1.4.0",
+ "spacetimedb-lib 1.5.0",
+ "spacetimedb-sats 1.5.0",
"spacetimedb-vm",
@@ -6927,3 +6927,3 @@ dependencies = [
name = "test-client"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
@@ -6939,3 +6939,3 @@ dependencies = [
name = "test-counter"
-version = "1.4.0"
+version = "1.5.0"
dependencies = [
diff --git a/Cargo.toml b/Cargo.toml
index b3c6d3222..f84eff4df 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -94,3 +94,3 @@ debug = true
[workspace.package]
-version = "1.4.0"
+version = "1.5.0"
edition = "2021"
@@ -100,34 +100,34 @@ rust-version = "1.88.0"
[workspace.dependencies]
-spacetimedb = { path = "crates/bindings", version = "1.4.0" }
-spacetimedb-auth = { path = "crates/auth", version = "1.4.0" }
-spacetimedb-bindings-macro = { path = "crates/bindings-macro", version = "1.4.0" }
-spacetimedb-bindings-sys = { path = "crates/bindings-sys", version = "1.4.0" }
-spacetimedb-cli = { path = "crates/cli", version = "1.4.0" }
-spacetimedb-client-api = { path = "crates/client-api", version = "1.4.0" }
-spacetimedb-client-api-messages = { path = "crates/client-api-messages", version = "1.4.0" }
-spacetimedb-codegen = { path = "crates/codegen", version = "1.4.0" }
-spacetimedb-commitlog = { path = "crates/commitlog", version = "1.4.0" }
-spacetimedb-core = { path = "crates/core", version = "1.4.0" }
-spacetimedb-data-structures = { path = "crates/data-structures", version = "1.4.0" }
-spacetimedb-datastore = { path = "crates/datastore", version = "1.4.0" }
-spacetimedb-durability = { path = "crates/durability", version = "1.4.0" }
-spacetimedb-execution = { path = "crates/execution", version = "1.4.0" }
-spacetimedb-expr = { path = "crates/expr", version = "1.4.0" }
-spacetimedb-lib = { path = "crates/lib", default-features = false, version = "1.4.0" }
-spacetimedb-memory-usage = { path = "crates/memory-usage", version = "1.4.0", default-features = false }
-spacetimedb-metrics = { path = "crates/metrics", version = "1.4.0" }
-spacetimedb-paths = { path = "crates/paths", version = "1.4.0" }
-spacetimedb-pg = { path = "crates/pg", version = "1.4.0" }
-spacetimedb-physical-plan = { path = "crates/physical-plan", version = "1.4.0" }
-spacetimedb-primitives = { path = "crates/primitives", version = "1.4.0" }
-spacetimedb-query = { path = "crates/query", version = "1.4.0" }
-spacetimedb-sats = { path = "crates/sats", version = "1.4.0" }
-spacetimedb-schema = { path = "crates/schema", version = "1.4.0" }
-spacetimedb-standalone = { path = "crates/standalone", version = "1.4.0" }
-spacetimedb-sql-parser = { path = "crates/sql-parser", version = "1.4.0" }
-spacetimedb-table = { path = "crates/table", version = "1.4.0" }
-spacetimedb-vm = { path = "crates/vm", version = "1.4.0" }
-spacetimedb-fs-utils = { path = "crates/fs-utils", version = "1.4.0" }
-spacetimedb-snapshot = { path = "crates/snapshot", version = "1.4.0" }
-spacetimedb-subscription = { path = "crates/subscription", version = "1.4.0" }
+spacetimedb = { path = "crates/bindings", version = "1.5.0" }
+spacetimedb-auth = { path = "crates/auth", version = "1.5.0" }
+spacetimedb-bindings-macro = { path = "crates/bindings-macro", version = "1.5.0" }
+spacetimedb-bindings-sys = { path = "crates/bindings-sys", version = "1.5.0" }
+spacetimedb-cli = { path = "crates/cli", version = "1.5.0" }
+spacetimedb-client-api = { path = "crates/client-api", version = "1.5.0" }
+spacetimedb-client-api-messages = { path = "crates/client-api-messages", version = "1.5.0" }
+spacetimedb-codegen = { path = "crates/codegen", version = "1.5.0" }
+spacetimedb-commitlog = { path = "crates/commitlog", version = "1.5.0" }
+spacetimedb-core = { path = "crates/core", version = "1.5.0" }
+spacetimedb-data-structures = { path = "crates/data-structures", version = "1.5.0" }
+spacetimedb-datastore = { path = "crates/datastore", version = "1.5.0" }
+spacetimedb-durability = { path = "crates/durability", version = "1.5.0" }
+spacetimedb-execution = { path = "crates/execution", version = "1.5.0" }
+spacetimedb-expr = { path = "crates/expr", version = "1.5.0" }
+spacetimedb-lib = { path = "crates/lib", default-features = false, version = "1.5.0" }
+spacetimedb-memory-usage = { path = "crates/memory-usage", version = "1.5.0", default-features = false }
+spacetimedb-metrics = { path = "crates/metrics", version = "1.5.0" }
+spacetimedb-paths = { path = "crates/paths", version = "1.5.0" }
+spacetimedb-pg = { path = "crates/pg", version = "1.5.0" }
+spacetimedb-physical-plan = { path = "crates/physical-plan", version = "1.5.0" }
+spacetimedb-primitives = { path = "crates/primitives", version = "1.5.0" }
+spacetimedb-query = { path = "crates/query", version = "1.5.0" }
+spacetimedb-sats = { path = "crates/sats", version = "1.5.0" }
+spacetimedb-schema = { path = "crates/schema", version = "1.5.0" }
+spacetimedb-standalone = { path = "crates/standalone", version = "1.5.0" }
+spacetimedb-sql-parser = { path = "crates/sql-parser", version = "1.5.0" }
+spacetimedb-table = { path = "crates/table", version = "1.5.0" }
+spacetimedb-vm = { path = "crates/vm", version = "1.5.0" }
+spacetimedb-fs-utils = { path = "crates/fs-utils", version = "1.5.0" }
+spacetimedb-snapshot = { path = "crates/snapshot", version = "1.5.0" }
+spacetimedb-subscription = { path = "crates/subscription", version = "1.5.0" }
diff --git a/LICENSE.txt b/LICENSE.txt
index 7c5f3cfff..d6571c196 100644
--- a/LICENSE.txt
+++ b/LICENSE.txt
@@ -7,3 +7,3 @@ Parameters
Licensor: Clockwork Laboratories, Inc.
-Licensed Work: SpacetimeDB 1.4.0
+Licensed Work: SpacetimeDB 1.5.0
The Licensed Work is
@@ -23,3 +23,3 @@ Additional Use Grant: You may make use of the Licensed Work provided your
-Change Date: 2030-09-22
+Change Date: 2030-09-29
diff --git a/crates/cli/src/subcommands/project/rust/Cargo._toml b/crates/cli/src/subcommands/project/rust/Cargo._toml
index d2a3da80f..2bd500e78 100644
--- a/crates/cli/src/subcommands/project/rust/Cargo._toml
+++ b/crates/cli/src/subcommands/project/rust/Cargo._toml
@@ -11,3 +11,3 @@ crate-type = ["cdylib"]
[dependencies]
-spacetimedb = "1.4"
+spacetimedb = "1.5"
log = "0.4"
diff --git a/licenses/BSL.txt b/licenses/BSL.txt
index 125fcf25a..e35adb65f 100644
--- a/licenses/BSL.txt
+++ b/licenses/BSL.txt
@@ -7,3 +7,3 @@ Parameters
Licensor: Clockwork Laboratories, Inc.
-Licensed Work: SpacetimeDB 1.4.0
+Licensed Work: SpacetimeDB 1.5.0
The Licensed Work is
@@ -23,3 +23,3 @@ Additional Use Grant: You may make use of the Licensed Work provided your
-Change Date: 2030-09-03
+Change Date: 2030-09-29
```
- [x] `cargo bump-versions 1.5.0 --typescript`
```
diff --git a/crates/bindings-typescript/package.json b/crates/bindings-typescript/package.json
index 2a3ac1d8b..e313ce262 100644
--- a/crates/bindings-typescript/package.json
+++ b/crates/bindings-typescript/package.json
@@ -2,3 +2,3 @@
"name": "spacetimedb",
- "version": "1.4.0",
+ "version": "1.5.0",
"description": "API and ABI bindings for the SpacetimeDB TypeScript module library",
```
- [x] `cargo bump-versions 1.5.0 --csharp`
```
diff --git a/crates/bindings-csharp/BSATN.Codegen/BSATN.Codegen.csproj b/crates/bindings-csharp/BSATN.Codegen/BSATN.Codegen.csproj
index 1b4193828..f9d87e31b 100644
--- a/crates/bindings-csharp/BSATN.Codegen/BSATN.Codegen.csproj
+++ b/crates/bindings-csharp/BSATN.Codegen/BSATN.Codegen.csproj
@@ -4,3 +4,3 @@
<AssemblyName>SpacetimeDB.BSATN.Codegen</AssemblyName>
- <Version>1.4.0</Version>
+ <Version>1.5.0</Version>
<Title>SpacetimeDB BSATN Codegen</Title>
diff --git a/crates/bindings-csharp/BSATN.Runtime/BSATN.Runtime.csproj b/crates/bindings-csharp/BSATN.Runtime/BSATN.Runtime.csproj
index 4ca49e0a0..781699c02 100644
--- a/crates/bindings-csharp/BSATN.Runtime/BSATN.Runtime.csproj
+++ b/crates/bindings-csharp/BSATN.Runtime/BSATN.Runtime.csproj
@@ -4,3 +4,3 @@
<AssemblyName>SpacetimeDB.BSATN.Runtime</AssemblyName>
- <Version>1.4.0</Version>
+ <Version>1.5.0</Version>
<Title>SpacetimeDB BSATN Runtime</Title>
diff --git a/crates/bindings-csharp/Codegen/Codegen.csproj b/crates/bindings-csharp/Codegen/Codegen.csproj
index e701d4b44..d5a60956c 100644
--- a/crates/bindings-csharp/Codegen/Codegen.csproj
+++ b/crates/bindings-csharp/Codegen/Codegen.csproj
@@ -4,3 +4,3 @@
<AssemblyName>SpacetimeDB.Codegen</AssemblyName>
- <Version>1.4.0</Version>
+ <Version>1.5.0</Version>
<Title>SpacetimeDB Module Codegen</Title>
diff --git a/crates/bindings-csharp/Runtime/Runtime.csproj b/crates/bindings-csharp/Runtime/Runtime.csproj
index 361f7db4d..a5492c4d3 100644
--- a/crates/bindings-csharp/Runtime/Runtime.csproj
+++ b/crates/bindings-csharp/Runtime/Runtime.csproj
@@ -4,3 +4,3 @@
<AssemblyName>SpacetimeDB.Runtime</AssemblyName>
- <Version>1.4.0</Version>
+ <Version>1.5.0</Version>
<Title>SpacetimeDB Module Runtime</Title>
diff --git a/crates/cli/src/subcommands/project/csharp/StdbModule._csproj b/crates/cli/src/subcommands/project/csharp/StdbModule._csproj
index 65e514c72..63ebb94a8 100644
--- a/crates/cli/src/subcommands/project/csharp/StdbModule._csproj
+++ b/crates/cli/src/subcommands/project/csharp/StdbModule._csproj
@@ -10,3 +10,3 @@
<ItemGroup>
- <PackageReference Include="SpacetimeDB.Runtime" Version="1.4.*" />
+ <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.*" />
</ItemGroup>
diff --git a/demo/Blackholio/server-csharp/StdbModule.csproj b/demo/Blackholio/server-csharp/StdbModule.csproj
index cd429eb32..5fbfde1b9 100644
--- a/demo/Blackholio/server-csharp/StdbModule.csproj
+++ b/demo/Blackholio/server-csharp/StdbModule.csproj
@@ -15,3 +15,3 @@
<ItemGroup>
- <PackageReference Include="SpacetimeDB.Runtime" Version="1.0.0" />
+ <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.*" />
</ItemGroup>
diff --git a/sdks/csharp/SpacetimeDB.ClientSDK.csproj b/sdks/csharp/SpacetimeDB.ClientSDK.csproj
index 27ba3ab72..14c04bfe4 100644
--- a/sdks/csharp/SpacetimeDB.ClientSDK.csproj
+++ b/sdks/csharp/SpacetimeDB.ClientSDK.csproj
@@ -18,4 +18,4 @@
<RepositoryUrl>https://github.com/clockworklabs/com.clockworklabs.spacetimedbsdk</RepositoryUrl>
- <AssemblyVersion>1.4.0</AssemblyVersion>
- <Version>1.4.0</Version>
+ <AssemblyVersion>1.5.0</AssemblyVersion>
+ <Version>1.5.0</Version>
<DefaultItemExcludes>$(DefaultItemExcludes);*~/**</DefaultItemExcludes>
@@ -27,3 +27,3 @@
<ItemGroup>
- <PackageReference Include="SpacetimeDB.BSATN.Runtime" Version="1.4.*" />
+ <PackageReference Include="SpacetimeDB.BSATN.Runtime" Version="1.5.*" />
diff --git a/sdks/csharp/examples~/quickstart-chat/server/StdbModule.csproj b/sdks/csharp/examples~/quickstart-chat/server/StdbModule.csproj
index 633b214b7..29344f061 100644
--- a/sdks/csharp/examples~/quickstart-chat/server/StdbModule.csproj
+++ b/sdks/csharp/examples~/quickstart-chat/server/StdbModule.csproj
@@ -16,3 +16,3 @@
<ItemGroup>
- <PackageReference Include="SpacetimeDB.Runtime" Version="1.4.*" />
+ <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.*" />
</ItemGroup>
diff --git a/sdks/csharp/examples~/regression-tests/server/StdbModule.csproj b/sdks/csharp/examples~/regression-tests/server/StdbModule.csproj
index 65e514c72..63ebb94a8 100644
--- a/sdks/csharp/examples~/regression-tests/server/StdbModule.csproj
+++ b/sdks/csharp/examples~/regression-tests/server/StdbModule.csproj
@@ -10,3 +10,3 @@
<ItemGroup>
- <PackageReference Include="SpacetimeDB.Runtime" Version="1.4.*" />
+ <PackageReference Include="SpacetimeDB.Runtime" Version="1.5.*" />
</ItemGroup>
diff --git a/sdks/csharp/package.json b/sdks/csharp/package.json
index 4585de204..025dfc6c1 100644
--- a/sdks/csharp/package.json
+++ b/sdks/csharp/package.json
@@ -3,3 +3,3 @@
"displayName": "SpacetimeDB SDK",
- "version": "1.4.0",
+ "version": "1.5.0",
"description": "The SpacetimeDB Client SDK is a software development kit (SDK) designed to interact with and manipulate SpacetimeDB modules..",
```
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
|
||
|
Zeke Foppa
|
ea61c949e1 |
Bump versions to 1.5.0, update DLLs, and regenerate files (#3310)
# Description of Changes Bumping versions to 1.5.0 since we have merged some new features (at the very least, https://github.com/clockworklabs/SpacetimeDB/pull/3292) # API and ABI breaking changes None # Expected complexity level and risk 1 # Testing None --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Phoebe Goldman
|
351af50578 |
Support BytesSources other than the one for reducer args (#3294)
# Description of Changes Each reducer gets its arguments through an `ArgSource`, a Unix-file-like abstraction for streams of bytes. Prior to this commit, we had an ABI designed as if it could support other args sources, but it actually hardcoded the ID of the reducer args source, and errored elsewhere. This commit extends the `BytesSource` infrastructure to support other bytes sources. This will be useful for exposing JWT payloads and HTTP responses. No other `BytesSource` uses are actually included in this commit, only the infrastructure. This commit also defines a new host call, `bytes_source_remaining_length`. This is intended to allow callers to pre-allocate a buffer correctly sized to read the entire `BytesSource` all at once. The new host function is added to a new ABI minor version, 10.1, so that old SpacetimeDB hosts can detect and reject too-new compiled modules. I have added uses of this new function to `__call_reducer__` in both Rust and C#, even though it's not strictly necessary, and I haven't removed the loop which repeatedly calls `bytes_source_read` and grows the buffer. # API and ABI breaking changes Adds a new ABI minor version, `spacetime_10.1`. This means that old SpacetimeDB hosts will reject new compiled modules. # Expected complexity level and risk 2-ish? WASM ABI code is always fiddly, but this is a pretty simple case. # Testing - [x] New behavior and new host function are both hit through existing tests that instantiate modules and call reducers against them, so I believe automated testing is sufficient. --------- Signed-off-by: Phoebe Goldman <phoebe@goldman-tribe.org> Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io> Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com> |
||
|
Mazdak Farrokhzad
|
2743d0bae3 |
SATS: impl ser/de for tuples (#3292)
# Description of Changes Implements `Serialize` and `Deserialize` for tuples. Extracted from https://github.com/clockworklabs/SpacetimeDB/pull/3276. # API and ABI breaking changes None # Expected complexity level and risk 2 # Testing A test `roundtrip_tuples_in_different_data_formats` is added. |
||
|
Jason Larabie
|
26e99fe5e5 |
Added the Unreal SDK work for codegen, testing, and the plugin (#3223)
# Description of Changes Closes #3219 This adds the Unreal SDK, the new Unreal test cases, updates the test runner to handle Unreal, codegen updates for Unreal, and a QuickStart Chat. # API and ABI breaking changes No breaking changes. # Expected complexity level and risk 2 - This impacts the subcommand generate.rs to include unrealcpp and crates/testing to expand for Unreal # Testing - [x] Run the new Unreal tests - [x] Run any previous automation testing - with all the changes to generate/testing I'm uncertain if there is an impact - [x] Review the new CLI generate documentation changes --------- Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org> Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
Jeffrey Dallatezza
|
1d08167ebd |
Store client credentials in a new system table (#2983)
# Description of Changes This adds a new system table to store the jwt payloads of connected clients. I'm planning to use this system table to expose client claims to modules in subsequent PRs. The new table is called `st_connection_credentials`. It is a **private** system table which stores a mapping from `connection_id` to `jwt_payload`. Note that a jwt payload is a json representation of the clients claims, not a fully signed token. The times when we need to insert and delete these rows closely mirrors that of the existing `st_client` table, with 1.5 exceptions: 1. We weren't previously inserting to `st_client` until after the `OnConnect` reducer ran (even though it was in the same transaction). We want `st_connection_credentials` to be populated before calling the reducer, so that the reducer can use it get the credentials, so I made a change to insert to `st_client` and `st_connection_credentials` before calling the reducer. 2. This difference has not actualized, but when clients start sending refresh tokens, we will probably need to update the credentials stored in this table. This also enforces uniqueness of connection ids. A duplicate connection id will now make the on-connect reducer fail (since it will violate uniqueness when trying to insert to `st_connection_credentials`). # Expected complexity level and risk 2.5 Adding a system table is a bit risky. This is almost rollback safe, with one annoying case that is worth calling out: If a database is created with this system table, opening it with an older version of spacetimedb will only work if there is a snapshot of the database. If we try to load a table without a snapshot, replaying will fail on the first row for that table. This is because we don't write the table schema information to the commit log when creating a database. In practice, this is unlikely to be an issue, because new databases asynchronously trigger a snapshot immediately after creation. Migrating existing databases will be fine. On startup this will detect that there is a missing system table, and add it in a way that writes it to the commit log. Since it is in the commit log, we can open the database with an older version and still understand the data for that table. # Testing There are unit tests that cover opening a database created with an older version (which doesn't have this table). I manually tested opening a migrated database with an older version of spacetimedb. |
||
|
Mario Montoya
|
8adef2b93b |
Support for the PG wire protocol (#2702)
# Description of Changes Closes [#2686](https://github.com/clockworklabs/SpacetimeDB/issues/2686). Add support for listening using the [PG wire protocol](https://www.postgresql.org/docs/current/protocol.html) so `pg` clients could be used against the database. # API and ABI breaking changes The output of `duration` is changed to `rfc3339`, instead of the way is made with `sats` because is what is done in `pg`, see note below. # Expected complexity level and risk 2 ~~There is open questions that are in the [ticket #2686](https://github.com/clockworklabs/SpacetimeDB/issues/2686). Also the crate used here require `RustTls`, so it could be good idea to decide if~~: * ~~Rewrite a big chunk of code to use `OpenSSL`~~ * ~~Move to `RustTls` https://github.com/clockworklabs/SpacetimeDB/pull/1700~~ * ~~Pay for the extra compilation cost~~. I open another port(`5433`) to listen for `pg` connections using `ssl`. Need to be decided if this is the way or instead try to multi-plex the current port for both protocols. # Testing Only manual testing so far. Solving the above questions allow me to implement some unit tests. Also, not yet integrated into cloud for the same reasons. - [x] Adding some test for the binary encoding of special and primitive types - [x] Smoke test using `psql` that connect to the db instance and run some queries - [x] Manually inspect using a UI database explorer how infer the types, some of this tools generate special widgets when displaying `json, duration, etc` --------- Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
Shubham Mishra
|
2c74f73550 |
Endpoint for pretty print migration plan (#3137)
# Description of Changes - Adds endpoint for for pretty printing migration plan. - It also changes current `publish` endpoint to optionally provide `MigrationToken` and `MigrationPolicy` to allow migration with breaking clients. # API and ABI breaking changes Backward compatible change to existing API and new Api # Expected complexity level and risk 2 # Testing - Existing smoketest should cover changes for `publish` endpoint. - For pretty print endpoint, smoketests can be written only after cli changes. --------- Signed-off-by: Shubham Mishra <shivam828787@gmail.com> Co-authored-by: James Gilles <jameshgilles@gmail.com> Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io> |
||
|
Kim Altintop
|
f394de32d9 |
Confirmed reads (#3133)
# Description of Changes Implements [subscribing to durable commits](https://github.com/clockworklabs/SpacetimeDBPrivate/issues/1594). The setting works on a per-connection level, and essentially just delays sending transaction updates until the transaction is reported as durable by the database. For connectionless SQL operations, the setting works per-request. No SQL syntax is provided by this patch to toggle the configuration. After some deliberation, I opted to obtain the offset when a transaction commits (as opposed to when it starts). This creates some mild inconvenience, because we prevent the transaction from committing until the corresponding subscription updates are enqueued. The strategy is, however, more correct should we ever support weaker isolation levels, and it is easier to document. Follow-ups include: - Provide SQL syntax (`SET synchronous_commit = ON` or something) - C# and TypeScript SDKs - Reference docs? # API and ABI breaking changes Not breaking, but adds a parameter to the subscribe and sql endpoints. # Expected complexity level and risk 4 To the author's understanding, ordering of outbound messages is not changed by this patch, even if there are messages that don't have a transaction offset (such as error messages). I.e. while waiting for the transaction offset of a message to become durable, no message enqueued after that message will be delivered. This may not be desirable in some cases. The patch may contain concurrency bugs, e.g. awaiting futures that may never resolve. # Testing - [x] Implemented a new test in the `module_subscription_actor` module - [x] Added unit tests for the core logic in `ClientConnectionReceiver` It would be desirable to also have integration-level tests, but I'm currently unsure how to write those without being able to control if and when the database reports an offset as durable. --------- Signed-off-by: Kim Altintop <kim@eagain.io> Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io> |
||
|
Jeffrey Dallatezza
|
33430cbe5c |
Dont use sentinel ids for system tables. (#3209)
# Description of Changes This simplifies system table bootstrapping logic by removing auto-incremented ids for indexes, constraints, and sequences in system tables. By defining them all up front, we avoid the need for `reset_system_table_schemas`, and make it easier to add new things to system tables. This change should not change the initial system table rows written during bootstrapping, and the `load_1_2_*` tests in `relational_db.rs` should verify that by loading data written by a previous version with and without a snapshot. I also added some sequence-related changes. The sequence schema previous included the `allocated` field, which tracked where to start generating new values after a restart. This made some checks awkward, since the 'schema' was changing as rows were inserted. I moved this outside of the `schema`, so those should no longer change unless something actually changes the shape of the tables. As part of that, I also changed where we begin generating on startup to be `allocated` instead of `allocated + 1`. The code that generates values always stopped early enough to allow the next restart to use `allocated`, so we were just being overly defensive. We also had some issues if sequences wrapped over, or if we had sequences with negative increments. Those were supported by the schema, but didn't really work with the generation/allocation code. That should have better testing now. # Expected complexity level and risk 2. The bootstrapped system tables should match, since we have tests with older data. The changes to sequences include some more invariant checking, which has some risk of causing problems if previous versions wrote values that I didn't consider. # Testing This has existing tests covering bootstrapping and restoring from a snapshot. |
||
|
Tyler Cloutier
|
5901fb5063 |
Separate out TypeScript module library from the SDK (#3182)
# Description of Changes Please note, much of the code changed in this PR is generated code. This change updates the TypeScript SDK to use a new `spacetimedb` TypeScript library which lives under the `/crates/bindings-typescript` folder alongside `/crates/bindings-csharp`. Just like with the C# bindings library, the types for `AlgebraicType` and `RawModuleDef` are now code generated with a script in `/crates/codegen/examples`. Pulling this out into a library allows us to use the same types and serialization code on both the server and the client for TypeScript modules. In the process of making this change I also found and fixed several issues with the TypeScript code generation. Namely an issue with recursive types and an issue with the `never` type. I also removed any use of `namespace`s since those are a TypeScript only feature, and we want to have JavaScript + types so that we can use the generated code with ESBuild without TSC. I have also improved the npm/pnpm scripts to be able to generate TypeScript code for us automatically by running `pnpm generate` for any place that we have to generate typescript code. Namely: - Quickstart module bindings - AlgebraicType/ModuleDef for TypeScript module library - Client API messages for the TypeScript API - TestApp module bindings # API and ABI breaking changes IMPORTANT! This is an API breaking change for clients, as such it should be a major version change. However, I am going to see if I can shim in the old API as best as possible to make it compatible. Notably, we were previously exporting APIs that end users do not need, and I don't think it would ever occur to them to use, namely the whole `AlgebraicValue` API and also the `AlgebraicType` API. In principle, no one should have a need for these, although it was technically possible for them to use it. Indeed, we could potentially even just remove AlgebraicType completely from the API by directly code generating the serialization code. Listed below are all of the **BREAKING** changes to the API and their effect: - `AlgebraicType` is now a structural union literal type instead of a class (nominal type), this is a consequence of generating the type with our code gen. Users did not have a reason to use `AlgebraicType` directly. - The `AlgebraicValue` type has been removed entirely. This was previously a class that was exported from the SDK, but very unlikely to be used by users. - The `ProductValue` type has been removed. - The `ReducerArgsAdapter` and `ValueAdapter` types, which were used with AlgebraicValues have been removed. - Generated code has changed incompatibly so users will have to regenerate code when upgrading to this version. Technically a breaking change, but pretty easy to fix. Listed below are the non-breaking API changes: - I am now exporting generated product types as the default export in addition to how I was exporting them before - For generated sum type `T`, I am now exporting a `TVariants` namespace which has the types of all the variants for `T`. This was previously exposed on the namespace `T`, but was inaccessible in modules other than the one it was defined in because I also export a type `T` in addition to namespace `T` and in the type position `T` was being interpreted as a type rather than a namespace. It's unclear why TypeScript resolved it as the `T` namespace within the module in which is was defined previously. Anyway, since the old types were apparently unobservable to users, I've replaced them with the types in `TVariants`. (Open to other names for this namespace). - I fixed a bug where never types (sum types with no variants) were not correctly generated. # Expected complexity level and risk 3. The most complex thing about the PR are the potential impacts to the API. I am reasonably certain, but not 100% certain that I have accounted for everything above. # Testing - [x] I ran `pnpm test` which runs all the tests in the repo including an integration test which tests the connection to SpacetimeDB. I also fixed broken tests. --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Zeke Foppa
|
726345206f |
CI - License checks (#3197)
# Description of Changes - Checks that all `LICENSE`/`LICENSE.txt` files are symlinks to something in `licenses/` - Checks that all license symlinks are valid - Adds Tyler as a codeowner for `LICENSE` # API and ABI breaking changes None. # Expected complexity level and risk 2 # Testing - [x] new CI fails on this PR (because https://github.com/clockworklabs/SpacetimeDB/pull/3193 isn't merged yet) - [x] new CI passes on a test PR with https://github.com/clockworklabs/SpacetimeDB/pull/3193 merged in (https://github.com/clockworklabs/SpacetimeDB/pull/3198) --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |