|
|
|
|
|
|
by jka
1485 days ago
|
|
|
Do you have any plans to handle schema changes for the content stored within the CRDTs as the clients evolve? (I've been puzzling over that question during some local-first dabbling; I have a feeling that lenses[1] -- or something like them -- may provide a route towards schema version upgrades without any peer synchronization guarantees) [1] - https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslide... |
|
|
The foundation of our approach is to have a versioned, documented schema shared among clients. Every write down to the individual attribute level is persisted with a schema version. We're already several versions in, and indeed think it's healthy to get experience with version updates frequently so that it's not an unusual occurrence.
Currently we use this schema to interpret / coerce values as needed at read-time. For example we see an attribute has schema version 1, and know that it should be interpreted in the sense that we meant as of version 1. In the future, we may also choose to write out updates for "migrations" where that'd be helpful. So that e.g. instead of having to re-interpret values for older version 1, we'd right out an update to he attribute that overwrites the old value and updates the version tag to e.g. 3.
We do think lenses are interesting and the lab from which we spun out has done some good work with them: https://www.inkandswitch.com/cambria/. They're just a bit complex for our modest needs re: schema versioning at this time.