couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Mitchell <>
Subject Re: rev hash stability
Date Fri, 17 Oct 2014 19:15:10 GMT
I agree on the anti-pattern. Concurrency control seems to be more of a cluster property. I
do think, however, that the optimization isn’t a “bad” thing. It just shouldn’t be
a requirement
for operation and never be relied upon as an assumption.

Simply put: if and only if the revs match we should assume some optimism just like we
do with things like atts_since. There’s already a lot of trust between two nodes for replication
and we should assume that matching revs were either unique (or random) or based on some
deterministic property that isn’t likely to collide unless it was an equivalent operation.

I’d encourage PouchDB to keep random revs unless they have some internal need to change
it. Even then, I think it’s PouchDB’s choice to generate revs however it wants as long
as it
follows these semantics.


> On Oct 17, 2014, at 9:20 AM, Dale Harvey <> wrote:
> Does anyone have a compelling reason for this optimisation existing?
> I cant think of many reasons for a user to be sending the same writes to
> different servers then not wanting them to conflict, I feel like its an
> anti pattern and I feel like if I make seperate writes and they dont
> conflict when I replicate, something is broken. Considering where there are
> a lot of huge and fairly easy wins in replication, spending any time on
> this almost never touched case doesnt seem worth it.
> PouchDB just uses random revs, the only people that have cared have known
> the inner working of couchdb, a pouchdb user has never been confused by the
> behaviour as far as I can remember.
> On 17 October 2014 13:45, Alexander Shorin <> wrote:
>> Hi Chris,
>> I'd already opened an issue to track this down:
>> If anyone has some plan, it better to be there.
>> --
>> ,,,^..^,,,
>> On Fri, Oct 17, 2014 at 3:38 PM, Chris Anderson <>
>> wrote:
>>> Wouldn't it be cool if we all generated interoperable revision hashes?
>>> I can't point any fingers because as far as I can tell, Couchbase is
>>> promulgating at least 3 different revision hash generation schemes.
>>> I've filed an issue for us here:
>>> Part of the problem is CouchDB's use of term_to_binary:
>>> I've seen this discussed informally, but I don't know if anyone has a
>>> tractable plan to get us there.
>>> Cheers,
>>> Chris
>>> --
>>> Chris Anderson  @jchris

View raw message