feature: logical clock history and logical snapshots

jchris commented 9 months ago

The changes api should return the resulting clock head of each change in the history. User agents can use this to load the database at any snapshot.

Keep in mind:

[ ] loading a snapshot should disconnect any remotes, we don't want time travel to be contagious
[ ] the desired behavior can probably be accomplished today by mutating the db._crdt.clock.head but we want a safer API
[ ] this is distinct from an API for loading the database from storage snapshots, this is more about navigating the logical clock history, that is more about storage snapshot and rollback. they are similar because currently each storage snapshot corresponds to each database operation, but that might change as we add more indexing options, etc

jchris commented 9 months ago

here is a code tour: https://chat.openai.com/share/c1f74595-5538-4d6d-91ca-3c1753732be8

jchris commented 9 months ago

here is GPT generated code from the tour https://gist.github.com/jchris/0fcb5c65031a8f75085e4287a5d28e12

jchris commented 9 months ago

[ ] just start by getting per row clock on changes and we'll merge that

jchris commented 9 months ago

It didn't write tests. Maybe next step is paste the source of this describe block in and have it add to the changes one here: https://github.com/fireproof-storage/fireproof/blob/38c4e050e350edc6df58870ca6777c8428f0b007/packages/fireproof/test/database.test.js#L82

valorant-dhruv commented 9 months ago

0001-Issue-21-Updates-to-changes-API.patch

fireproof-storage / fireproof

feature: logical clock history and logical snapshots #21