# Description of Changes
Fixes#3926. This PR bundles in icudata (11MB) to the spacetime binary,
to allow i18n functions like `String.prototype.localeCompare()` to work.
The 2nd commit sets the default locale to [en-001, "International
English"](https://www.ctrl.blog/entry/en-001.html), in order to prevent
system locale from affecting the execution of reducers.
# Expected complexity level and risk
1
# Testing
- [x] Verify this fixes the issue.
NOTE: Cherry-picking
https://github.com/clockworklabs/SpacetimeDB/pull/4127 from the
`2.0-breaking-changes` branch.
## Original PR Description
This changes generated types in ts client bindings. We currently
generate a few different types of types: reducer args, procedure args,
rows, and user defined types. To avoid potential conflicts between these
types (for example, if a user defined a type called `FooRow`, and also
had a tabled named `foo`, we would end up with two types named
`FooRow`), this puts each set of types in a different file and
namespace. We also stopped exporting the `xxxRow` types, because there
is always another type generated for those. We now have a `types`
directory, which has an `index.ts` with user defined types, along with
`reducers.ts` and `procedures.ts` for the types generated for
reducer/procedure parameters.
```
import type * as Types from './module_bindings/types';
var currentMessages: Types.Message[] = [];
```
or
```
import { type Message } from './module_bindings/types';
var currentMessages: Message[] = [];
```
This has a couple other changes:
- For procedure and reducer types, this adds a suffix of `Args`, since
we may want types for the return values in the future.
- For all of the types, instead of exposing the schema object, we are
now giving the typescript type (e.g. `export type Message =
__Infer<typeof MessageRow>;`). I couldn't think of a reason for users to
want the schema object, so this should save users from needing to do all
of the `Infer` boilerplate.
This is a breaking change for v2.
2. This only changes typescript, and it should generally make thing
easier to use.
---------
Co-authored-by: Jeffrey Dallatezza <jeffreydallatezza@gmail.com>
# Description of Changes
The PR implements the following updates:
- Create a quickstart guide and client support for using SpacetimeDB
directly in browser with script tags
- A template to easily work with/test the implementation and get started
with script tags
The bundle is served via
`https://unpkg.com/spacetimedb@latest/dist/browser.bundle.js`, which
only works after the package is published to npm, therefore to test
locally we can use the `browser-ts` template and local bundle:
1. Build local bundle
```
cd crates/bindings-typescript
pnpm install
pnpm build
```
2. Use local bundle built in template`index.html` (swap the URL from
`unpkg`)
```diff
- <script src="https://unpkg.com/spacetimedb@latest/dist/browser.bundle.js"></script>
+ <script src="../../crates/bindings-typescript/dist/browser.bundle.js"></script>
```
3. Open `browser-ts/index.html` directly in browser along with
`spacetime start` + publish the module `spacetime publish --project-path
spacetimedb browser-ts`
# Screenshots
<img width="1106" height="707" alt="image"
src="https://github.com/user-attachments/assets/715bea26-f54b-42be-97f9-79dcd57d153f"
/>
<img width="1490" height="855" alt="image"
src="https://github.com/user-attachments/assets/2b1aeaf9-22ba-4ae6-bc63-771805b8c2b9"
/>
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- maybe a test you want to do -->
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
---------
Co-authored-by: = <cloutiertyler@gmail.com>
This reverts commit fd3cdb3d0b.
# Description of Changes
Reverts #4105, We do not actually need `__describe_module_v10__`, as
original describe reducer returns `enum` - `crates:lib::RawModuleDef`
which is extended to add a variant for `V10`
# API and ABI breaking changes
NA
# Expected complexity level and risk
1
# Testing
Existing tests should be enough
# Description of Changes
Blocks procedures from requesting private ip ranges after dns
resolution.
Adds a new cargo feature to `spacetimedb-standalone` permitting loopback
http requests in test environments only.
# API and ABI breaking changes
None
# Expected complexity level and risk
2. I may have missed a range.
# Testing
- [x] Unit tests for IP address matching
- [x] Smoketests for blocking a private IP address
# Description of Changes
V8 Modules to expose `RawModuleDefV10`
# API and ABI breaking changes
It breaks client, hence should be merged in `2.0-breaking-changes`
# 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! -->
- [ ] Existing smoketests with run on new module def to verify if its
correct.
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Noa <coolreader18@gmail.com>
# Description of Changes
This is the implementation of the Typed Query Builder for C# modules
outlined in #3750.
This requires the changes from #4146 to be in place before it can
properly function.
This aligns the C# typed query builder SQL formatter with the Rust
implementation:
* Supports `And/Or` with same grouping styles as Rust.
* All comparison operators (`Eq/Neq/Lt/…`) wrap expressions in
parentheses so chained predicates produce byte-for-byte identical SQL.
# API and ABI breaking changes
Not breaking. Existing modules keep producing the same SQL semantics;
only redundant parentheses were added to match the Rust formatter.
# Expected complexity level and risk
2 — localized string-format updates plus parity harness tweaks. Low
functional risk; largest concern is ensuring every comparison path
gained parentheses.
# Testing
- [X] Tested against a local test harness validating output from these
changes match current Rust behavior.
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
In order to give reviewers a chance to finish in one session the docs
are getting split up for the C++ update. This pass contains the
following section update:
- Tables
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - Just documentation additions
# Testing
- [x] Manually tested each block
# Description of Changes
In order to give reviewers a chance to finish in one session the docs
are getting split up for the C++ update. This pass contains the
following section update:
- Unity Blackholio Tutorial
- Unreal Blackholio Tutorial
- Added /demo/Blackholio/server-cpp
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - Just documentation additions
# Testing
- [x] Manually tested each block
# Description of Changes
Added @bfops and @jdetter as codeowners for a bunch of the CI-related
stuff, since it is nontrivial infrastructure.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
None
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
In order to give reviewers a chance to finish in one session the docs
are getting split up for the C++ update. This pass contains the
following section update:
- Functions
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - Just documentation additions
# Testing
- [x] Manually tested each block
# Description of Changes
In order to give reviewers a chance to finish in one session the docs
are getting split up for the C++ update. This pass contains the
following section updates:
- Intro
- Databases
- How To
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - Just documentation additions
# Testing
- [x] Manually tested each block
# Description of Changes
The PR adds some benchmarks meant to compare how we encode composite
indices for primitive types today (`_AV`) versus how we intend to store
them in the future.
These benchmarks sample the standard uniform distribution for some
static types, e.g., `(i32, i32, u64)` and then either converts them to
how we store keys today (`_AV`, stands for `AlgebraicValue`), or encodes
them into a byte-array (`_Enc`, stands for "encoded), e.g., `[u8; 16]`
in the case of the bitcraft index, which is what the future optimization
would entail.
The comparison for each type is then between `_AV` and `_Enc`.
Here are some numbers on an i9-14900K:
```
IFoldHash<I32xI32xU64_AV>/insert_random
time: [85.817 ns 87.344 ns 88.648 ns]
IFoldHash<I32xI32xU64_Enc>/insert_random
time: [41.329 ns 42.217 ns 43.120 ns]
IFoldHash<I32xI32xU64_AV>/seek_random
time: [108.48 ns 111.47 ns 114.05 ns]
IFoldHash<I32xI32xU64_Enc>/seek_random
time: [43.468 ns 45.974 ns 48.468 ns]
IFoldHash<I32xI32xU64_AV>/delete_random
time: [112.36 ns 120.10 ns 127.67 ns]
IFoldHash<I32xI32xU64_Enc>/delete_random
time: [49.078 ns 51.745 ns 54.182 ns]
```
These benchmarks strongly suggest that the future optimization will be
highly profitable.
# API and ABI breaking changes
None
# Expected complexity level and risk
0, not even trivial :)
# Testing
Nothing to test / this is benchmark code only.
If the `dev` command encounters an HTTP error when fetching module logs,
it relies on the server to also send some error description in the
response body.
That isn't always the case, so default to the status code + canonical
reason phrase
# Expected complexity level and risk
1
# Testing
n/a
# Description of Changes
CI is currently failing in a bunch of places since we tweaked the Rust
versions available in our CI runner, and it revealed that many of our
workflows don't set the default rust toolchain.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
- [x] CI passes in this PR
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
When the durability rejects a write due to being already closed,
include the database identity in the panic payload.
# Expected complexity level and risk
1
# Testing
n/a
# Description of Changes
Switch Wasm module to `__describe_module_v10__` from
`__describe_module__` to expose `RawModuleDefV10`.
Note: Originally merged into the 2.0 breaking changes branch
https://github.com/clockworklabs/SpacetimeDB/pull/4115.
# API and ABI breaking changes
2.0 breaking change.
# Expected complexity level and risk
1
# Testing
Exising smoketests should be enough.
---------
Co-authored-by: Shubham Mishra <shivam828787@gmail.com>
# Description of Changes
This adds C++ server bindings (/crate/bindings-cpp) to allow writing C++
20 modules.
- Emscripten WASM build system integration with CMake
- Macro-based code generation (SPACETIMEDB_TABLE, SPACETIMEDB_REDUCER,
etc)
- All SpacetimeDB types supported (primitives, Timestamp, Identity,
Uuid, etc)
- Product types via SPACETIMEDB_STRUCT
- Sum types via SPACETIMEDB_ENUM
- Constraints marked with FIELD* macros
# API and ABI breaking changes
None
# Expected complexity level and risk
2 - Doesn't heavily impact any other areas but is complex macro C++
structure to support a similar developer experience, did have a small
impact on init command
# Testing
- [x] modules/module-test-cpp - heavily tested every reducer
- [x] modules/benchmarks-cpp - tested through the standalone (~6x faster
than C#, ~6x slower than Rust)
- [x] modules/sdk-test-cpp
- [x] modules/sdk-test-procedure-cpp
- [x] modules/sdk-test-view-cpp
- [x] Wrote several test modules myself
- [x] Quickstart smoketest [Currently in progress]
- [ ] Write Blackholio C++ server module
---------
Signed-off-by: Jason Larabie <jason@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
https://github.com/clockworklabs/SpacetimeDB/pull/4209 changed our v8
patch to fix release builds.. but it turns out that the csharp-testsuite
uses both debug _and_ release builds.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
I dunno mannnn
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Required in order to bump rolldown to its latest version, which I'm
planning to do afterwards. I also figure we may as well do this before
releasing a major version.
# Expected complexity level and risk
2
# Testing
n/a
# Description of Changes
Same changes as https://github.com/clockworklabs/SpacetimeDB/pull/4101
but for `connection_id`.
# API and ABI breaking changes
API Breaking
# Expected complexity level and risk
1
# Testing
Pure refactor. Tests and docs have been updated, but no new tests added.
# Description of Changes
Basically, cut down on creating new objects in the hot path as much as
possible.
# Expected complexity level and risk
1
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- maybe a test you want to do -->
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
# Description of Changes
Moves the `root/sdks/csharp/packages/` directory from the
`root/sdks/csharp/.gitignore` to `root/.gitignore`.
This is to resolve Issue #4207 , which was introduced during the DLLs
generation rework.
`/sdks/csharp/packages/` should be ignored by git, to prevent locally
generated DLLs from accidentally getting added to the repo.
**Root cause:**
When Unity imports a package by URL, it looks at the `.gitignore` list
and filters by it, causing the entire `packages` directory to not be
imported. In earlier versions of Unity (like `2022.3` where this was
initially tested), this was not a problem because Unity would allow us
to do a `dotnet restore`. In modern version of Unity, this is no longer
allowed as all imported packages are considered immutable.
Because the `/sdks/csharp/` is cloned into
`com.clockworklabs.spacetimedbsdk`, if we move at what level the
`root/sdks/csharp/packages/` is ignored at, we can prevent the
accidental inclusion of the DLLs from developers in the SpacetimeDB
repo, while ensuring `com.clockworklabs.spacetimedbsdk` does not contain
a reference to ignore the `packages` directory.
# API and ABI breaking changes
No API or ABI changes
# Expected complexity level and risk
1
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] Tested removing the `packages` directory from the `.gitignore`
list on a custom branch of `com.clockworklabs.spacetimedbsdk` to observe
the behavior in both Unity `6000.3.2f1` and `2002.3.62f2`.
# Description of Changes
Makes the `sender` field on `ViewContext` private and exposes a
`sender()` method. Does the same for `ReducerContext` and
`ProcedureContext`.
The purpose of this change: So that the host can determine if/when a
view invokes or reads the `sender`.
Currently, because `sender` is a field, the host assumes that it is
always read. This means views must be materialized per client, even if
the view doesn't actually depend on `sender`, resulting in data
duplication.
The initial solution for this problem was `AnonymousViewContext` which
doesn't have a `sender` field. The better solution is to make `sender` a
method so that it can call into the host and record when it's actually
invoked.
Note, this patch only updates the module API, so the current
implementation does not change. `ViewContext` views are still duplicated
across clients. Changing this requires a new host syscall and for
`sender()` to invoke that syscall. This however is backwards compatible
and can be done anytime after the module APIs for the other languages
(C#, TypeScript, C++) are updated.
Also note that `ReducerContext` and `ProcedureContext` were updated
purely for consistency. There are currently no plans to track reads of
`sender` in these contexts.
# API and ABI breaking changes
Breaks the rust module api.
# Expected complexity level and risk
1
# Testing
N/A
# Description of Changes
The main difference from v1 is that syscalls that used to return
`Uint8Array`s now instead accept `ArrayBuffer`s and write into them.
This greatly improves performance, since the module can now reuse
buffers when calling into the host, instead of the host allocating anew
on every call.
To see the changes from v1 -> v2, you can check the diff between the
head of this branch and the "Copy v1.rs to v2.rs" commit.
# API and ABI breaking changes
Not sure whether this counts? A new ABI, but we're not breaking the old
one.
# Expected complexity level and risk
3 - mostly the same as the old one
# Testing
No change in behavior, and the typescript package will use the new ABI
even though its API isn't changing (yet).
---------
Co-authored-by: centril <twingoow@gmail.com>
# Description of Changes
When reading the docs, I noticed that even though TypeScript is included
in most of the examples, the text at the top of the 'Key Architecture'
section doesn't mention it as a language that can be used to write
Modules.
This change simply adds TypeScript to the list of languages that can be
used to write Modules.
This is my first ever pull request, so my apologies if this change is
considered too small.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
I've not done any testing considering the size of the changes.
Signed-off-by: Luuk Domhof <60610562+ExpLuuk@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
We were using `cargo install` but doing our hacky v8 dance for debug
build outputs. `cargo install` runs in release mode though.
This came up in https://github.com/clockworklabs/SpacetimeDB/pull/4205.
# API and ABI breaking changes
None. CI only
# Expected complexity level and risk
1
# Testing
🤷
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
- Codegen to skip creating reducer and procedure file if `visibility ==
FunctionVisiblity::Internal`
- `UpdateHost` to check for visibility before excuting reducers and
procedures.
# API and ABI breaking changes
NA, master is not exposing new raw module version yet.
# Expected complexity level and risk
1. While the current patch is simple, could there be other places where
visibility should also be applied?
# Testing
Smoketest can be in `2.0-breaking-changes` branch once we merge this.
Exising test should cover for regression
# Description of Changes
Fixes https://github.com/clockworklabs/SpacetimeDB/issues/2298.
The general idea is to avoid moving around types that are 400+ bytes or
so only to eventually pass them by reference.
Just pass them by ref as soon as possible instead.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Covered by existing tests.
# Description of Changes
This PR translates all of our Python smoketests into Rust tests which
can be run from `cargo run`
## Motivation
The purpose of this fivefold:
1. All developers on the team are familiar with Rust
2. It simplifies our devops because we can drop Python as a dependency
to run the tests
3. You can now run all tests in the repo through the single `cargo test`
interface
4. Because we use the `SpacetimeDbGuard` and `cargo test`/`cargo
nextest` we can easily parallelize the smoke tests
5. The smoketests can now use machinery imported from SpacetimeDB crates
(e.g. `bsatn` etc.)
IMPORTANT NOTE!
There are several ways to implement the smoke tests in Rust (none are
great):
1. A separate xtask specifically for the smoke tests
- This doesn't solve the problem of the CLI tests which also use the
`guard` crate
- Idiosyncratic way to run the smoke tests as opposed to cargo test
- Does NOT resolve the cargo within cargo problem because we still have
to build the test modules with cargo
2. A `build.rs` script in `guard` which first builds the executables as
a compile step for compiling guard
- Deadlocks on a cargo lock file conflict (Outer cargo compiles guard →
runs build.rs, inner cargo tries to acquire the build directory lock,
outer cargo holds the directory lock, deadlock)
- If you fix the deadlock by using different target dirs, it still looks
stuck on building guard because it's actually compiling all of
spacetimedb-standalone and spacetimedb-cli.
- Still technically runs cargo inside of cargo.
3. Add `spacetimedb-cli` and `spacetimedb-standalone` as an artifact
dependency of the guard crate
- Has good and clear output but requires +nightly when running the
smoketests and CLI tests, otherwise won't do the right thing. See
https://github.com/rust-lang/cargo/issues/9096
4. Compile the executables at runtime during the tests themselves where
the first test takes a lock while the executables are building using
cargo within cargo
- Makes the tests look like they're taking a long time when they're just
waiting for the build to complete
- Requires relatively complex locking machinery across
binaries/tests/processes
5. A two step solution where the developer has to build the binaries
before calling the smoke tests
- Very error prone
None of these are good. `xtask` is not bad, but doesn't enable us to run
other integration tests in other crates (e.g. the CLI)
(3) is the correct solution and has the best user experience, but it
requires nightly and I don't want to introduce that for all of our
tests.
I have chosen to do a combination of (1) and (4). You will now run the
smoketests with `cargo smoketest`. If you run `cargo test --all` (or use
`guard`) without doing `cargo smoketest` it will fall back to (4) which
compiles the executables at runtime. Running `cargo build` is the **only
way** to ensure that the executables are not stale because of the
internal fingerprint checking. Everything else is fragile not robust.
NOTE! There is no way to avoid cargo within cargo and have the smoke
tests be run as cargo tests because the modules under test must be
compiled with cargo.
# API and ABI breaking changes
Note that this is a BREAKING CHANGE to `cargo test --all`. The
smoketests are now part of `cargo test --all` unless you specifically
exclude them.
# Expected complexity level and risk
3, this is partially AI translated. We need to carefully review to
ensure the semantics have not regressed.
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- maybe a test you want to do -->
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
The goal of this PR is to:
- Make it easy to switch our backing implementation of identifiers, as
seen in the commit changing to `LeanString`.
- Improve type safety of our identifiers by having every identifier
start with `RawIdentifier` and then `Identifier` is just a wrapper with
validation on construction. `TableName` and `ReducerName` are then just
wrappers around `Identifier`.
- Reduce allocation in `InstanceEnv` by using the now clone-on-write
O(1) + SSO optimized `Identifier`.
- Reduce allocations in the query engine as a consequence of improving
`RawIdentifier` and `Identifier`.
- Have `&'static str` strings be further optimized by avoiding to
allocate even for long ones. This is supported by `impl From<&'static
str> for RawIdentifier` as well as switching to `LeanString`.
The PR results in a roughly 2k TPS improvement over master for WASM +
hash indices. This should also help V8, as this is VM-agnostic.
# API and ABI breaking changes
None
# Expected complexity level and risk
3? Mostly just small changes in many places, but in a sea of small
changes, mistakes can happen.
# Testing
Covered by existing tests.
# Description of Changes
And more precisely pin the Cargo dep, along with a comment.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1
# Testing
- [x] `nix build` now exits 0 and produces runnable binaries locally.
(`nix flake check` is still broken.)
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- This was blocking the release and is now blocking a CI check that
@bfops added in private.
# 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] CI is passing
# Description of Changes
Ignoring nuget config files regardless of casing, as well as in the root
directory since we generate them there now.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
- [x] Files generated by `write-nuget-config.sh` are now properly
ignored
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
The script was running `cd` but using the STDB path as passed, so if it
was run from e.g. the root directory, it would generate incorrect paths.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Running `sdks/csharp/tools~/write-nuget-config.sh .` from the root
directory generates a `NuGet.Config` that uses correct paths
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This moves a bunch of stuff from `lib` back into `server` and `sdk`, and
removes all but one global variable from the server sdk in preparation
for export-based reducer definition.
# Expected complexity level and risk
2 - a pretty big refactor, but it's mostly just code movement.
# Testing
- [x] Refactor, so automated tests are sufficient.
# Description of Changes
This particular line lost during rebasing of prev PRs.
Now causing 2.0 branch to fail -
https://github.com/clockworklabs/SpacetimeDB/pull/4115
# API and ABI breaking changes
NA
# Expected complexity level and risk
0
# Description of Changes
Tiny addition to the llm context to explain that maincloud publishing is
free of charge
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Ran claude code with updated context and it performed better in the
publishing step
# Description of Changes
This should optimize better than walking the AlgebraicType tree on every
call. I'll do some profiling to confirm, but I am already using it in my
performance experiments.
# Expected complexity level and risk
2 - fully rewrites the bsatn encoder/decoder, but it's a fairly simple
format.
# Testing
- [x] Automated testing
- [x] Profiling
# Description of Changes
This patches a regression introduced in
[#4033](https://github.com/clockworklabs/SpacetimeDB/pull/4033) where
cargo ci dlls stopped copying the Unity .meta files that live outside
the package skeleton tree:
1. `overlay_unity_meta_skeleton` now copies any
`sdks/csharp/unity-meta-skeleton~/spacetimedb.<pkg>.meta` file into
`sdks/csharp/packages/` before overlaying nested content.
2. Added support for a `version.meta` template inside each skeleton
package; it’s renamed to match the single restored version directory
(e.g. `1.11.2.meta`).
3. Added the missing `version.meta` templates for both
`spacetimedb.bsatn.runtime` and `spacetimedb.runtime`, based on the
historical GUIDs Unity already knows about.
Together this restores the `spacetimedb.bsatn.runtime.meta` and
`<version>.meta` files that Unity requires to keep those folders visible
when developers run `cargo ci dlls` on a clean checkout.
# API and ABI breaking changes
None. This only affects the CI helper responsible for syncing Unity
metadata.
# Expected complexity level and risk
2 — localized changes to the CI helper and skeleton assets. Primary risk
is forgetting a template or mis-copying a GUID; the code paths
themselves are straightforward.
# Testing
- [X] Ran `cargo check -p ci`
- [X] Ran `cargo ci dlls` on a clean tree, verifying that:
* `sdks/csharp/packages/spacetimedb.bsatn.runtime.meta` exists
* The restored version directory (e.g.
`sdks/csharp/packages/spacetimedb.bsatn.runtime/1.11.2.meta`) exists
- [X] Locally launched Unity with a SpacetimeDB project and had no
errors/issues.
# Description of Changes
This got a little bigger than I had hoped, but I think it's still pretty
manageable. This PR partially reverts back to before #3263: cores are
re-balanced with a `watch::Receiver<CoreId>` that each database thread
will listen for updates on in order to repin itself, and multiple OS
threads (each matched to a database) can be pinned to one core. As I
understand it, that second part is something Phoebe was trying to avoid,
but given that there's no way to asyncify a JS module, it's kind of
necessary.
JS is single-threaded, and uses cooperative rather than preemptive
multitasking (callbacks/async, not green threads). That means that if a
JS function has an infinite loop, no other event handlers would be able
to run unless that loop were to exit. Coupled with the fact that we
can't `Send` a v8 isolate across threads, it makes more sense to keep
the module host on one thread and repin that thread as needed. An
alternative option, as was brought up, would be to deconstruct and
reconstruct the module onto a different thread when needed, since
load-balancing won't be happening often anyway.
# Expected complexity level and risk
3 - reworks the threadpool that databases run on, and so could lead to
deadlocks or other concurrency bugs. However, that seems unlikely, since
this separates databases each onto their own thread, and as such
decreases the likelihood of them interacting poorly with each other.
# Testing
Not sure if there's anything specific I should do, since this doesn't
change behavior.
- [ ] <!-- maybe a test you want a reviewer to do, so they can check it
off when they're satisfied. -->
---------
Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Copied from: https://github.com/clockworklabs/SpacetimeDB/pull/4084
We originally reverted this because it was causing testsuite flakes in
private. Now we have solved the issue that was causing the flakes so
this should be safe to merge.
Version upgrade to `v1.12.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 - this is just a version upgrade
<!--
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! -->
The testsuite failures are fixed by
https://github.com/clockworklabs/SpacetimeDB/pull/4120
- [x] License has been properly updated including version number and
date
- [x] CI passes
---------
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This workflow change migrates us from docker container runners to the
new system which uses virtual machines via qemu. This solves a lot of
complexities around docker-in-docker and also allows us to easily run
windows VMs in the future.
# 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
0 - this only updates our workflow and has no impact on the code.
<!--
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] CI is passing
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
This change implements the module bindings changes to Views that where
updated with core in #3685 and the Rust module bindings implementation
in #3819.
Updates the C# module bindings to use new header-first view ABI
(`ViewResultHeader`) and updates the return codes for the
`__call_view__` and `__call_view_anon__` module exports. This is a
prerequsite for `Query` builder support being added to C# modules.
# API and ABI breaking changes
Not breaking. Existing modules will continue to use the old ABI. New
modules will use the new ABI. However previous host versions will not
support modules built using this version of the bindings.
# Expected complexity level and risk
2
# Testing
This is an internal refactor. All existing tests should continue to
pass. All existing tests should continue to pass. The only tests that
needed updating were the C# codegen snapshot tests (`Codegen.Tests`)
because the generated view dispatcher bodies changed (they now prefix
`ViewResultHeader.RowData` before the existing row payload).
# Description of Changes
This has been popping up in more places, so I've added this in more
places.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
🤷
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Noa