mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-13 11:17:50 -04:00
tyler/opencode
330 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
843f9eb6d1 | Experimenting with spacetime code | ||
|
|
73881e38f7 |
Further misc docs changes (#4029)
# Description of Changes Major documentation overhaul focusing on tables, column types, and indexes. **Quickstart Guides:** - Updated React, TypeScript, Rust, and C# quickstarts with table/reducer examples - Fixed CLI syntax (positional `--database` argument) - Improved template consistency across languages **Tables Documentation:** - Added "Why Tables" section explaining table-oriented design philosophy (tables as fundamental unit, system tables, data-oriented design principles) - Added "Physical and Logical Independence" section explaining how subscription queries use the relational model independently of physical storage - Added brief sections linking to related pages (Visibility, Constraints, Schedule Tables) - Renamed "Scheduled Tables" to "Schedule Tables" throughout (tables store schedules; reducers are scheduled) **Column Types:** - Split into dedicated page with unified type reference table - Added "Representing Collections" section (Vec/Array vs table tradeoffs) - Added "Binary Data and Files" section for Vec<u8> storage patterns - Added "Type Performance" section (smaller types, fixed-size types, column ordering for alignment) - Added complete example struct demonstrating all type categories - Renamed "Structured" category to "Composite" **Indexes:** - Complete rewrite with textbook-style documentation - Added "When to Use Indexes" guidance - Documented single-column and multi-column index syntax (field-level and table-level) - Comprehensive range query examples with correct TypeScript `Range` class syntax - Explained multi-column index prefix matching semantics - Added index-accelerated deletion examples - Included index design guidelines **Styling:** - Added CSS for table border radius and row separators - Created Check component for green checkmarks in tables # API and ABI breaking changes None. Documentation only. # Expected complexity level and risk 1 - Documentation changes only, no code changes. # Testing - [ ] Verify docs build without errors - [ ] Review rendered pages for formatting issues - [ ] Confirm code examples are syntactically correct --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com> Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
|
fb01448068 |
impl MemoryUsage for TxState (#4054)
# Description of Changes Add `impl MemoryUsage for TxState` and all the types below. Extracted from https://github.com/clockworklabs/SpacetimeDB/pull/3831 to reduce the diff to ease figuring out why its not helping perf. # API and ABI breaking changes None # Expected complexity level and risk 1 |
||
|
|
ef61c7c123 |
In-memory DatabaseLogger (#3961)
This is the second step to make in-memory-only databases not touch the disk at all. While at it, also make it so file-backed module logs are streamed in constant memory where possible. Depends-on: #3912 # Expected complexity level and risk 2 # Testing Added some unit-level tests. --------- Signed-off-by: Kim Altintop <kim@eagain.io> Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io> |
||
|
|
a9892aae0e |
Fix logic for ipv6 connections in is_port_available (#4005)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> - Small fix for checking to see if a port is available on some given interface. updated: The original implementation here used `bind` to try to discover if a port is currently in use. This isn't reliable due to platform differences - especially on windows where it's apparently acceptable to have a service running on both `0.0.0.0:3000` and `127.0.0.1:3000`. This would cause bind to return successfully when we wanted it to fail. Also: binding on an ipv6 interface when a machine doesn't have ipv6 enabled caused random errors and it was too unreliable to be useful. This new implementation uses `get_socket_info` which returns info on all sockets in use on the system. We can then look through this list to find services which conflict with our requested port. updated 1/14: This PR now includes a fix for flaky CLI tests. Originally we were using `find_free_port` to pick a random free port, but that was causing a race condition which resulted in test flakes. This PR fixes this issue by using `127.0.0.1:0` as the listen addr so the kernel will automatically pick a free port for us. # 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 - this is a pretty isolated check, unlikely to introduce larger issues. # 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 tested on macos, windows and linux: ``` ALLOW docusaurus is already running on 127.0.0.1:3000 SpacetimeDB then tries to start on 192.168.1.10:3000 ALLOW docusaurus is already running on ::1:3000 SpacetimeDB then tries to start on 192.168.1.10:3000 DENY docusaurus is already running on ::1:3000 SpacetimeDB then tries to start on 127.0.0.1:3000 DENY docusaurus is already running on 0:0:0:0:0:0:0:0:3000 SpacetimeDB then tries to start on 0.0.0.0:3000 DENY docusaurus is already running on 0:0:0:0:0:0:0:0:3000 SpacetimeDB then tries to start on 127.0.0.1:3000 DENY docusaurus is already running on 0:0:0:0:0:0:0:0:3000 SpacetimeDB then tries to start on 192.168.1.10:3000 DENY docusaurus is already running on 127.0.0.1:3000 SpacetimeDB then tries to start on 0:0:0:0:0:0:0:0:3000 DENY docusaurus is already running on 192.168.1.10:3000 SpacetimeDB then tries to start on 0:0:0:0:0:0:0:0:3000 ``` |
||
|
|
c5bd1d8b9d |
Version bump to 1.11.3 (#4041)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> - Version bump to `v1.11.3` for just the CLI and rust # 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 <!-- 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] CLI version has been updated - [x] Version + date in the license file has been updated |
||
|
|
8544e6cf02 |
Add Hash indices (#3976)
# Description of Changes Fixes https://github.com/clockworklabs/SpacetimeDB/issues/1122. Adds hash indices and exposes them through `#[index(hash)]` for Rust modules, with support for typescript and C# to come in follow ups. On the client/sdk side, for now, any index is backed via a BTree/native index as it is the most general. A hash index may only be queried through point scan and never ranged scans. Attempting a ranged scan results in an error, with the mechanism implemented in the previous PR (https://github.com/clockworklabs/SpacetimeDB/pull/3974). # API and ABI breaking changes None # Expected complexity level and risk 2? # Testing A test for ensuring that hash indices cannot be used for range scans is added. Tests exercising hash indices will come in the next PR. |
||
|
|
8ab3ef4a19 |
Version bump to 1.11.2 (#3977)
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> - Version upgrade to `1.11.2` # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> - None, this is just a version bump # Expected complexity level and risk 1 - no real changes here <!-- 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 - NA this is just a version bump, no functionality change here. |
||
|
|
05d4874918 |
Create db.lock file only for persistent databases (#3912)
This is the first step to make in-memory only databases not touch the disk at all. Pending is an in-memory only sink for module logs. Responsibility for the lock file is transferred to `Durability`, which means that only persistent databases opened for writing acquire the lock. As a consequence, the `Durability` trait gains a `close` method that prevents further writes and drains the internal buffers, even when multiple `Arc`-pointers to the `Durability` exist. # Expected complexity level and risk 2 # Testing Covered by existing tests. |
||
|
|
b75bf6decf |
LLM Benchmarking (#3486)
# Description of Changes Introduce a new **LLM benchmarking app** and supporting code. * **CLI:** `llm` with subcommands `run`, `routes list`, `diff`, `ci-check`. * **Runner:** executes globally numbered tasks; filters by `--lang`, `--categories`, `--tasks`, `--providers`, `--models`. * **Providers/clients:** route layer (`provider:model`) with HTTP LLM Vendor clients; env-driven keys/base URLs. * **Evaluation:** deterministic scorers (hash/equality, JSON shape/count, light schema/reducer parity) with clear failure messages. * **Results:** stable JSON schema; single-file HTML viewer to inspect/filter/export CSV. * **Build & guards:** build script for compile-time setup; * **Docs:** `DEVELOP.md` includes `cargo llm …` usage. This PR is the initial addition of the app and its modules (runner, config, routes, prompt/segmentation, scorers, schema/types, defaults/constants/paths/hashing/combine, publishers, spacetime guard, HTML stats viewer). ### How it works 1. **Pick what to run** * Choose tasks (`--tasks 0,7,12`), or a language (`--lang rust|csharp`), or categories (`--categories basics,schema`). * Optionally limit vendors/models (`--providers …`, `--models …`). 2. **Resolve routes** * Read env (API keys + base URLs) and build the active set (e.g., `openai:gpt-5`). 3. **Build context** * Start Spacetime * Publish golden answer modules * Prepare prompts and send to LLM model * Attempt to publish LLM module 4. **Execute calls** * Run the selected tasks within each test against selected models and languages. 5. **Score outputs** * Apply deterministic scorers (hash/equality, JSON shape/count, simple schema/reducer checks). * Record the score and any short failure reason. 6. **Update results file** * Write/update the single results JSON with task/route outcomes, timings, and summaries. # API and ABI breaking changes None. New application and modules; no existing public APIs/ABIs altered. # Expected complexity level and risk **4/5.** New CLI, routing, evaluation, and artifact format. * External model APIs may rate-limit/timeout; concurrency tunable via `LLM_BENCH_CONCURRENCY` / `LLM_BENCH_ROUTE_CONCURRENCY`. # Testing I ran the full test matrix and generated results for every task against every vendor, model, and language (rust + C#). I also tested the CI check locally using [act](https://github.com/nektos/act). **Please verify** * [ ] `llm run --tasks 0,1,2` (explicit `run`) * [ ] `llm run --lang rust --categories basics` (filters) * [ ] `llm run --categories basics,schema` (multiple categories) * [ ] `llm run --lang csharp` (language switch) * [ ] `llm run --providers openai,anthropic --models "openai:gpt-5 anthropic:claude-sonnet-4-5"` (provider/model limits) * [ ] `llm run --hash-only` (dry integrity) * [ ] `llm run --goldens-only` (test goldens only) * [ ] `llm run --force` (skip hash check) * [ ] `llm ci-check` * [ ] Stats viewer loads the JSON; filtering and CSV export work * [ ] CI works as intended --------- Signed-off-by: bradleyshep <148254416+bradleyshep@users.noreply.github.com> Signed-off-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: Tyler Cloutier <cloutiertyler@aol.com> Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: spacetimedb-bot <spacetimedb-bot@users.noreply.github.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
|
8fb0bcf922 |
Add UUID built-in convenience type to SpacetimeDB (#3538)
# Description of Changes Closes [#3290](https://github.com/clockworklabs/SpacetimeDB/issues/3290). Adds a new "special" type to SATS, `UUID`, which is represented as the product `{ __uuid__: u128 }`. Adds versions of this type to all of our various languages' module bindings libraries and client SDKs, and updates codegen to recognize it and output references to those named library types. Adds methods for creating new UUIDs according to the V4 (all random) and V7 (timestamp, monotonic counter and random) specifications. # API and ABI breaking changes We add a new type # Expected complexity level and risk 2 it impacts all over the code # Testing - [x] Extends the Rust and Unreal SDK tests, and the associated `module-test` modules in Rust, C# and TypeScript, with uses of UUIDs. - [x] Extends the C# SDK regression tests with uses of UUIDs. - [x] Extends the TypeScript test suite with tests with uses of UUIDs. --------- Signed-off-by: Mario Montoya <mamcx@elmalabarista.com> Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io> Co-authored-by: Jason Larabie <jason@clockworklabs.io> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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. |
||
|
|
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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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> |
||
|
|
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. |
||
|
|
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. |
||
|
|
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. |
||
|
|
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> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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 |
||
|
|
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. |
||
|
|
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> |
||
|
|
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. |
||
|
|
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 |
||
|
|
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> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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. --> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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. |
||
|
|
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. --> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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>
|