On Feb 23, 2009, at 8:45 PM, Chris Anderson wrote:
Would it be overly difficult to just add in the ability to keep a
full rev
history based on a config setting?
This would be a pretty big change. As Antony says, once you go down
that path a little, you end up at something that is not really much
like Couch.
There's yet to be a really clear reference for how to do
application-versioned documents in CouchDB. Hopefully we'll address
the topic in the book, but we haven't gotten that far yet.
The way I see it, the salient options are:
A) leave it as _rev and answer the versioning question every week
forever
B) rename it to _mvcc or _lock or _token or something else that
doesn't confuse people
The main drawback of B is that when we start renaming _rev, someone
else comes along and tries to take the opportunity to change _id, or
otherwise change the whole system. If we can stick to just renaming to
something clearer, I'm happy to go ahead with this.
I forgot when I posted this, we still need the ability to get conflict
revisions, which also uses the ?rev=... syntax. Maybe we should change
that use from ?rev... to ?conflict=...., since those rev ids show up
in the _conflicts doc member.
I think if we change from _rev to something else, _cc for concurrency
control is good. I'm not sure this is necessary.
Maybe we should only allow the ability to getting old revisions (?
disk_rev=...) with a setting in the ini, defaulting it off. That
discourages it's use as general purpose mechanism, but is easy to turn
on if you really need it.
-Damien
