-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign "snapshots" to be "operations" #75
Comments
I just saw this got released recently, it's late here, but part of my brain says this may help It sounds about right, just layer each operation on top of each other to get the current 'state' of all the operations that have been applied.... |
Yeah, that is a great idea :) |
We would make operations work on top of old snapshots, so it wouldn't be a breaking change (i.e require removing/doing surgery on snapshots), and I think there may actually be a relatively simple way to do it, which would be simply to store a json patch or delta of some kind to the snapshot object.
Generally speaking, interleaving operations should be just fine after that, although there may need to be some small structural changes, e.g instead of keeping lists like [{name: "name"}] we will need to keep an object like {"name": {...}}. This can also be solved in a backwards compatible way by checking for lists when serializing old snapshots and converting to objects, no need to alter the old snapshot files or anything. |
We actually want to make these operations part of core, so that any extension can react to these changes. |
One small note: each operation should probably get its own file, or each batch. |
Right now, collaborating with multiple developers using the migration generator can be cumbersome. You have to remove any generated migrations locally, pull, and then regenerate migrations. This is because snapshots essentially are a linear process.
If we rearchitect this to use a single json file with an array of operations that have been generated, and then have the snapshots derived as a projection of those operations, then there will no longer be issues w/ multiple developers working together with the migration generator (e.g on different branches).
The text was updated successfully, but these errors were encountered: