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.
# 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>
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.
* Saving because I'm testing writing files
* New upgrade program working quite well
* Update license file as well
* Tool seems good to go
* Cargo check is passing, new upgrade-version is ready, old version
removed
* Updating lock file is required for CI to pass
* main.rs clippy lints
* More sensible default
* Version upgrade to 0.7.0 via new version-upgrade util
---------
Co-authored-by: Boppy <no-reply@boppygames.gg>
We've had continual issues with test isolation when developing breaking changes.
This commit doesn't fully address those, but is a step in the right direction:
the SDK tests now create a tempdir as their `STDB_PATH`,
rather than using `~/.spacetime`.
This switches tests from invoking a spacetimedb CLI found on PATH to always using up-to-date version by depending on the CLI crate as a library.
---------
Signed-off-by: Phoebe Goldman <phoebe@goldman-tribe.org>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
* Simple SDK test harness; SDK test module
Yet to come: actual SDK tests.
* Quiet clippy lint about "too many arguments"
* Lints are named with underscores, not dashes...
* Will this make clippy shut up?
* Go nuclear on disabling `too_many_attributes` lint. Sigh.
* WIP SDK test client, and fix bugs in Rust codegen
Compiling the module_bindings for the sdk-test module revealed two bugs:
- Enums holding structs generated incorrectly,
unpacking the struct into the enum's payload.
- Recursive types would cause the codegen to attempt to recursively import
the current module into itself.
* One (1) actual runnable test in the sdk crate
* Exclude test-client from CI
The sdk tests already build this crate (though they don't clippy or fmt it).
Attempting to build, test, fmt or clippy it as-is will fail
because the module_bindings are not committed.
This is intentional, as the SDK test suite wants to generate the module_bindings
during its run.
* Rustfmt ignore generated module_bindings
It turns out `cargo fmt` doesn't actually support the `--exclude` option
the way `cargo clippy` does.
Instead, just `#[rustfmt::skip]` the `mod module_bindings;` decl.
* Actually commit test file...
God, I'm so bad at remembering to commit new files.
Anyway, add a test for deleting rows with primitive unique fields.
* Make CLI tool available in tests workflow
The SDK tests need to run `spacetime start`, `spacetime generate` and `spacetime publish`.
* Test update events with primitive pk types; split test-client into files
* Tests with `Identity` fields in tables
* Tests for reducer callbacks, both successful and failing
* Tests with vecs of stuff, with structs, with enums
* Test that should fail, test that uses a large table with many columns
* Test for resubscribe functionality
* Test of reauth; fix major bug in `TestCounter`
I misread `Condvar::wait_timeout_while` as `Condvar::wait_timeout_until`,
and flipped my predicate.
This led to false negatives (i.e. tests that passed that shouldn't have).
* A fistful of doc comments
* Avoid race condition running multiple tests with same client project
This commit fixes a race condition which sometimes caused the SDK tests to fail
because multiple `spacetime generate` processes running concurrently
would clobber each others' output,
potentially deleting it while a `cargo build` or `cargo run` process was running.
Now, the test harness will only run `spacetime generate` at most once
for any given directory.
* Add env_logger to SDK test client
* RUST_LOG=trace when running test clients
* quieter logs in test client: only warn-level and higher
* Install from source instructions
* Improved comment
* Separate the global location of files per OS & create a configuration trait to read them
---------
Co-authored-by: Boppy <no-reply@boppygames.gg>
Kim Altintop