couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Fail on a simple case on replication
Date Tue, 24 Feb 2009 02:30:59 GMT

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.


View raw message