[ ] Remove sha256 from Revision. Rename id to index, and add a new field named id. The thought here is that index more accurately describes the numerical value being stored there. sequence_id seemed too verbose, and when thinking about it from the layperson's view, what does "sequence" even mean? The id field is a unique id for all revisions across a given collection, so the short name makes sense.
[ ] Implement collection migration process. I've pledged backwards compatibility, and all the information we need is in the database. I believe these sorts of upgrades should be able to be done transparently, but I also believe that some people will want to know there's a compatibility upgrade. So, there should be a configuration option that enables automatic upgrades -- disabled by default. If an upgrade is needed, an error should be returned.
Background
Sadly, in pondering #186 as well as #90, it occurred to me that there is no efficient way to retrieve a historical document given the current information. The only way to do so is to scan the history of the single key from the start to the revision being requested.
A few days ago it finally dawned on me what happened. The document design was written back when I planned on doing everything atop Sled, and there was no concept of a "sequence id". Back in those days, my plans for replication and clustering didn't include document history or master-master replication.
Then, I introduced Nebari, and we had a sequence ID. But it just never clicked that I should change from the SHA hash to the sequence id.
idtoindex, and add a new field namedid. The thought here is thatindexmore accurately describes the numerical value being stored there.sequence_idseemed too verbose, and when thinking about it from the layperson's view, what does "sequence" even mean? Theidfield is a unique id for all revisions across a given collection, so the short name makes sense.Background
Sadly, in pondering #186 as well as #90, it occurred to me that there is no efficient way to retrieve a historical document given the current information. The only way to do so is to scan the history of the single key from the start to the revision being requested.
A few days ago it finally dawned on me what happened. The document design was written back when I planned on doing everything atop Sled, and there was no concept of a "sequence id". Back in those days, my plans for replication and clustering didn't include document history or master-master replication.
Then, I introduced Nebari, and we had a sequence ID. But it just never clicked that I should change from the SHA hash to the sequence id.