A Couchbase 7.0 data model that befriends good migration techniques

Couchbase Server
1

Hi there,

We are considering updating our data model of Couchbase 7.0 (that uses scopes and collections) so that in near future, while in production, the data model may facilitate easy migration for most use-cases.

Here are my ideas:

  1. Document versioning can facilitate on-the-fly migration mechanisms but also batch. Checking the version number is much easier, given that the document update is atomic, which is. We just check the version and decide if the document requires an update or not. I found a blog post on document versioning, that suggests that ::v1 or ::v2. Is this still a best practice for Couchbase 7.0? Adding version numbers to collection names seems to be easier to implement and also less error-prone. What is the best practice for document versioning for Couchbase 7.0?
  2. On-the-fly migration must not only update document versions but also run 2-code versions, which can be extremely hard to do. I think a little downtime is OK for us while we do the migration in batch - for a while. So we should go for batch if required: the application starts up by upgrading the whole database and then it starts with the new code that is compatible with the new model.
  3. We name collections based on Java/Scala case class names based on class’ canonical name. Moving classes within packages and renaming classes would break our data model. Therefore when that happens, we must rename collections or move data to a new collection. Is it possible to rename collections it Couchbase 7.0? I found no evidence for that. Is it planned, if not possible?

Thanks!

Zoltán