couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Fail on a simple case on replication
Date Tue, 24 Feb 2009 10:46:08 GMT

On 24 Feb 2009, at 04:09, Jeff Hinrichs - DM&T wrote:

> On Mon, Feb 23, 2009 at 8:43 PM, Chris Anderson <>  
> wrote:
>> On Mon, Feb 23, 2009 at 6:30 PM, Damien Katz <>  
>> wrote:
>>> Maybe we should change that use from ?rev... to ?conflict=
>> If we follow your _cc idea, we could change from ?rev= to ?cc=
>>> I think if we change from _rev to something else, _cc for  
>>> concurrency
>>> control is good. I'm not sure this is necessary.
>> yes, if we make the change _cc is the best so far. I can already
>> imagine office workers thinking it stands for "conflict catcher".
>>> 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.
>> Not a bad idea. The idea that you can't depend on it being available
>> would discourage apps from attempting to use _cc as an easy way to
>> provide undo functionality for users. Undo is a good feature, but  
>> undo
>> that sometimes randomly has been compacted away is worse than no  
>> undo.
> I would point out that compaction is not a random event.  It is
> controlled by the admin, correct?  To my knowledge, couch does not
> spontaneously compact nor even currently support the idea of automated
> compaction.

You're right, but that's one use-case. I'm used to think in the  
mindset of
a shared hosting provider where users do all sorts of crazy things and
the admins need to be able to control sensible operation. I'm not saying
this is the only other use-case but I'm seeing the general case of  
users not being admins and this not controlling compaction. Hence,
old revisions could go away at any time and undo should not rely on
the revision system to provide this functionality.

> <devil's advocate>
> Also, earlier in the thread, Dean L, suggested allowing unlimited rev
> history.  I think that his idea has merit in light of a talked about
> patch that would limit revs history to length N.  If the ability to
> control the size(N) of rev history is in the cards, why not allow N to
> be infinity?  Before you just dismiss the idea, I would state that I
> could see usefulness for this in special cases and remind you of the
> old saw, "Accountants don't use erasers." And in the new age of
> security and compliance, Auditors don't like erasers.

We're not dismissing the usefulness. By no means, but the revision
system is the wrong place to put this from CouchDB's design standpoint.

A little history.

I've been bugging Damien to implement this ever since I started playing
with CouchDB in October '06*. Our final discussion (that was about a
year ago) that I should be coming up with an RFC that covers all angles
of distributeed editing and replication that makes this easy to  
He said he couldn't come up with an easy way yet and there are edge-
cases lurking that are really hard. Based on his experience with  
database and my lack of it, I stopped the bugging. When I ever have the
time to think this all through I might propose an RFC covering all  
and maybe a patch, but until then I keep quiet and work on providing
alternatives for users like the chapter in the Couch Book that Chris
hinted at.

Not saying it can't be done, but it is harder as it may sound, however
useful it is.

Lastly, there's so many other areas where the current CouchDB needs
improvement and where the vision and implementation details are much
clearer. Let's tackle them first.

* I'm not trying to be intimidating or showing of my cool, I'm just  
out that Damien has been saying "no" (well, "not yet") to this feature
for quite some time and for good reasons.

View raw message