mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-14 19:58:24 -04:00
joshua-spacetime
39f91270e1
# Description of Changes <!-- Please describe your change, mention any related tickets, and so on here. --> Defines auto-migration rules for views. > What are they? Answer: You can always auto-migrate a view. It's just a matter of whether you have to disconnect clients. Removal of a view or changing the return type in a breaking way requires that we disconnect clients. TODO: Even if a view is updated in a completely compatible way, we still have to wipe or dirty the read set in order to force a re-computation because the behavior could have changed. # 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. --> 2.5 Not just a mechanical change. Most of the time you can think of views as though they were tables. However for auto-migration there is a key distinction. Views don't have observably persistent state. While we can persist state internally, we can always derive a view's result set from the database state. Hence auto-migration rules are not as strict. # 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] Auto-migration planner tests
⚠️ Internal Crate ⚠️
This crate is intended for internal use only. It is not stable and may change without notice.