Migrations are a really hard problem for local-first, because (as the article says):
a. clients can be running old code that can’t handle the new schema
b. clients can write data locally using an old schema that you want to merge into the new schema
This solution is interesting - note the schema version for all writes and move writes made against an old schema earlier in the order of operations than the new schema migration.
Whether this works is quite dependent on the consistency model and merge semantics. The Cambria [0] approach is to use transformation functions (or “lenses”) to transform the local writes when applied to a backend or node with the new schema.
In either case, you still need an emergency mode that drops writes (loses data) if you can’t handle the transformations or reconcile the merge. For example, if the schemas have moved on too much or you’ve truncated your log so you can’t merge in very old writes.
Comments
Migrations are a really hard problem for local-first, because (as the article says):
a. clients can be running old code that can’t handle the new schema b. clients can write data locally using an old schema that you want to merge into the new schema
This solution is interesting - note the schema version for all writes and move writes made against an old schema earlier in the order of operations than the new schema migration.
Whether this works is quite dependent on the consistency model and merge semantics. The Cambria [0] approach is to use transformation functions (or “lenses”) to transform the local writes when applied to a backend or node with the new schema.
In either case, you still need an emergency mode that drops writes (loses data) if you can’t handle the transformations or reconcile the merge. For example, if the schemas have moved on too much or you’ve truncated your log so you can’t merge in very old writes.
[0] https://www.inkandswitch.com/cambria/