Is it really wrong to version documents using CouchDB's default behaviour?

Question

This is one of those \"I know I shouldn\'t do this but it\'s oh so convenient.\" questions. Sorry about that.

I plan to use CouchDB for storing a bunch of documents

Answer 1

If you reformulate the sentence a bit, it says: "Any update, regardless how minor can completely change the behavior. We guarantee you can use it for concurrency, but nothing else."

Therefore I would not rely on it because in our industry, stuff like that will haunt you in 6 months, unless you can absolutely guarantee that you never, ever update CouchDB.

Answer 2

If it's wrong, then I don't want to be right!

Actually, no. It's wrong. Michael explained it well: best case scenario it makes your app very not future-proof, and worst-case you will get bad bugs that force you to re-architect at an inconvenient time.

Consider Google App Engine. What is their suggested transaction pattern?

1. Begin transaction
2. Fetch your entities by key
3. Modify entities and save them
4. End transaction

These form a function which re-runs if the transaction fails. Why? And why must fetch be within the transaction instead of hanging around in an outer scope?

Because App Engine uses MVCC internally. If you get a collision (your revision is wrong because somebody else updated), then they just re-run your function. The next iteration will fetch the newer revision, update from the newer data, and re-put with a correct revision. The point is, Google does not expose this to users because it is not a suitable framework to build application-level versioning.