On Mon, Feb 23, 2009 at 8:43 PM, Chris Anderson <jch...@apache.org> wrote: > On Mon, Feb 23, 2009 at 6:30 PM, Damien Katz <dam...@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
