4 ms·
We need databases that are versioned, immutable, atomic, provide snapshots, and allow applications to decide what version of the database to query. For example
by throwaway787544 4y ago
We need databases that are versioned, immutable, atomic, provide snapshots, and allow applications to decide what version of the database to query.
For example, say your database has 10 columns of different types, and your schema change modifies it. Now you have at least two versions of the db. The app should be able to specify in its query what version of the db it wants to operate against. And if most of the rows of data weren't modified, it should be possible to copy-on-write changes between the two versions. And during the schema change, the old version should remain the live one, with the new version receiving updates until a flag flips the new version to the live version, with only a very brief window of lock for the last records to convert.
- JamesSwift 4y agoThats basically what datomic provides
- setr 4y agoIf you can insert into either before/after versions of the schema, I feel like it’d be possible to reach an irreconcilable state; eg if you add a unique constraint to your schema, but the app is inserting into the pre-constraint version of the schema, there’s no way to roll forward. Unless you have a migration script to specify the roll-forward logic, but then you’re just back to the same problem you have today. Immutable data I understand under a static schema, but I can’t imagine there’s a way to make immutable data under a dynamic schema sane