I have read this article about how to do document versioning with couchbase server. It is a bit old (4 years ago) but still useful. However there was not any reference to SG (maybe because it wasn’t exist at the time) and I’m trying to find a way to change document specifications over time.
I’m actually working in startup projects (with R-DBMS for now) where the schema and access permissions can change two times at month, so document versioning will be absolutely required.
In my current projects (rest api with sql database) doing this types of changes means:
- change object models
- update queries to match the new models and access changes
- create migrations document for altering tables
- do database migration and deploy code to production
What options are valid with SG?
After reading the article I think that document schema and access permissions need to be handled in different ways.
In the most cases I think the better is having a document with the last supported database schema change (or something similar for every document type).
This document need to be shared for every user, so every client could know if is old and cannot be run until the user update it. However this solves only the client side problem (knowing if the application can run properly), the big problem remain insoluted: how to keep track the document schema change?
Document version property without replication:
If the documents were updated in place the problem is about old clients that cannot read the document properly in case of:
- Property renaming
- Property deletion
- Property requirement change (eg: user reference denormalization, so from string now is a subdocument)
So essentially this means that using this method only the last version of the client can be used, and release of new client versions need to be handled in sync with sync function release, but in the middle the user will have a bad experience.
Document version embedding:
In this case the document contains all versions of that type until the last supported.
However, this means:
- Document size will grow a lot, based on the size of all document version summed.
- A changes feed to keep the versions updated is needed, because the old clients will update only their current last version (eg v2), but the new clients will use the new document version (v3).
- A lot of unnecessary data is synced to clients.
Document version property with replication:
With this case the document is replicated based on his version property (or maybe his type, embedding the document version inside the type property).
This resolve the document size problem, but the other two problems still remains (changes feed application and unnecessary data sync).
With this method every specification change is kept as a creation of a new bucket, which have the new documents specifications.
With this case the bucket will contains a new version of all documents, in its own correct format.
- Document migration is required from the last bucket into the new, this require to migrate sync gateways properties either (like users) so a couchbase server SDK is needed.
- A new changes feed application is needed for every version, that change the other version of documents in others buckets
- Sync user credentials could be a problem, because the user data is not referenced in the changes feed and so cannot be tracked to be updated into every bucket.
- This problem could be emarginated using a custom authentication system that update credentials in all buckets
- The sync function will be specific for every new version, so the older sync functions will be untouched in the release process, and no bugs for mixed rules can occur.
- Clients will have always to sync their current bucket, so they always have only one version of documents.
In essence: What is the more successfully document versioning method used into production evironments?
I’m trying to find a solution that:
- minify code written for each specific release
- minify possibly versioning related bugs
- permit at least two versions to coexist