couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hinrichs - DM&T" <dunde...@gmail.com>
Subject Re: Fail on a simple case on replication
Date Tue, 24 Feb 2009 03:09:24 GMT
On Mon, Feb 23, 2009 at 8:43 PM, Chris Anderson <jchris@apache.org> wrote:
> On Mon, Feb 23, 2009 at 6:30 PM, Damien Katz <damien@apache.org> 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.

>
>
<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.

scenario, master-slave -- slaves only keep the most recent, while the
master keeps complete. conflict resolution is handled solely by the
master.
scenario, first-among-equals -- multi-master where a single master is
used as the basis for conflict resolution, other masters keep only a
limited rev history and escalate to the first-among-equals when
Eventual Consistency can not be reached do to missing rev history on a
peer.

This is not an argument for changes to replication, or a desire for
replication with complete rev history.  Only to allow rev history size
of infinity.
</devil's advocate>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

Regards,

Jeff Hinrichs

Mime
View raw message