@alekcz360 That is super cool. Can you encode the version of each value in its first byte? I think we can probably generalize the serialization between the filestore and the couchdb and redis backend, because they write the metadata and value in one underlying value in the key-value store.
@whilo I can. The example in the filestore was only pushed recently. So I was a bit blind.
I'll add it to the two and then I can update the template repo too
@whilo quick question so the version will be 1 right?
yes, you can define a constant for it in the namespace
The idea is that you can just read the first byte and then decide whether you need to trigger a migration or can read the file right away.
Yeah that makes sense. That would be separate to get-version
right?
get-version on the store level is not strictly necessary, or would you see a use case for it?
It would basically do the same thing, but it is enough for it to do it on your byte representation directly before you read it. It does not need to know the full store.
The best case scenario would be storing the version separately to the data. Then access is inexpensive. Otherwise you need to download the object
{:meta {:key ....}
:data <object>
:version 1}
This would be possible in couch, postgres, firebase
Yes, but in general you already know that you want to access the object somehow when you read the version, .e.g. for get-meta
or get
. It is important that you do not have to fetch the value for get-meta
.