SpacetimeDB
SpacetimeDB copied to clipboard
clockworklabs
Pretty print auto-migration plans
Description of Changes
Implements https://github.com/orgs/clockworklabs/projects/22/views/16?filterQuery=migration&pane=issue&itemId=91111218.
While implementing this, I discovered auto-migration plans applied their steps in a nondeterministic order (I was iterating a hashmap and had forgotten to sort.)
This interacted in a particularly bad way with row-level-security policies:
- Row level security policies are removed and re-added in every automigration, to allow the core crate to re-initialize the relevant queries. (I disagree with this -- it should be an implementation detail of the core crate, not mentioned in auto-migrations -- but I'm not changing it in this PR; see my comments about it in the code.)
- Since ordering was random, the Add step for the policy could be run before the Remove step.
- Adding an already existing policy was implemented in an idempotent way by the core crate.
- So, any auto-migration could nondeterministically drop row-level-security policies!
This is now fixed by simply sorting the steps of an auto-migration in a prescribed way.
API and ABI breaking changes
This is a minor breaking change to the client API since it adds data to the result of an update call.
Expected complexity level and risk
0
Testing
Added a smoketest.
TODO: I want to add to the integration tests of the schema crate as well.
Please separate the bugfix from the new feature. These should be separate PRs.
Not my place but:
This is a minor breaking change to the client API since it adds data to the result of an update call.
Is that a breaking a change? It sounds purely additive, which I would've called not-api-breaking?
Converting to draft per https://github.com/clockworklabs/SpacetimeDB/pull/2065/files#r1910890326
