incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Is the revision field deterministic?
Date Wed, 09 Apr 2014 10:20:56 GMT

On 09 Apr 2014, at 09:24 , Robert Samuel Newson <> wrote:

> It’s not necessary for all things-that-work-with-couchdb to implement this particular
optimization (and that’s all it is). Reducing the occasions when _rev is different for two
documents in the exact same state is great but there’s no harm if it’s not achieved.
> I think it would be a mistake to define the _rev calculation as its current implementation.


At the same time, it might be worth considering a portable way to make this optimisation and
change it in CouchDB, so other implementations have a chance of opting into it.


> B.
> On 9 Apr 2014, at 01:26, Dale Harvey <> wrote:
>> Sorry, I meant in the case in which the same document was posted to
>> different servers that replicated
>> On 9 April 2014 01:09, Mark Hahn <> wrote:
>>>> by not conflicting the users loses information
>>> By not conflicting, do you mean two docs with different content having same
>>> rev?  How is this possible?  I thought the original poster on this thread
>>> said he was wrong about that.
>>> On Tue, Apr 8, 2014 at 4:56 PM, Dale Harvey <> wrote:
>>>> Yup I almost mentioned PouchDB when I seen this thread come up, from an
>>>> external implementors perspective it isnt great that CouchDB uses the
>>>> internal erlang binary term format to create revisions, its possible to
>>>> implement it compatibly but decided against it due to extra deps +
>>>> complexity
>>>> From an API perspective I believe its a leaky abstraction, I havent
>>> tested
>>>> this but it seems like if the binary term format changes between erlang
>>>> versions then the same code can have different behaviour, similiarly
>>>> possible between couch versions.
>>>> Also I just dont think its a great idea, by not conflicting the users
>>> loses
>>>> information, its easy for audit software to force conflicts by adding the
>>>> target id to the documents, but yeh it still makes me feel weird.
>>>> And yup while unfortunately named, Couchbase Lite is very much along the
>>>> same lines as PouchDB, with a different target platform. (we even stole
>>> the
>>>> same replication optimisations :))
>>>> Cheers
>>>> Dale
>>>> On 9 April 2014 00:36, Jens Alfke <> wrote:
>>>>> On Apr 8, 2014, at 8:34 AM, Alexander Shorin <>
>>>>>> Jens, is that was another uncanny attempt to adv. unrelated product
>>>>>> without providing relevant information? These actions only confuses
>>>>>> people forcing them thinking that Couchbase and CouchDB are the
>>>>>> similar products while they don't.
>>>>> Nope. Couchbase *Lite* and CouchDB _are_ very similar. They have the
>>>> exact
>>>>> same data model, a 95% similar REST API*, and can replicate with each
>>>>> other. (The implementations are entirely different, though, because
>>>>> Couchbase Lite is meant to be embedded in mobile apps.)
>>>>> Couchbase Lite is at least as similar to CouchDB as PouchDB is, and no
>>>> one
>>>>> complains about PouchDB being mentioned here.
>>>>> Couchbase *Server* is a different beast entirely. It was wrong of me
>>>>> discuss it here last week; apologies again.
>>>>> I know the names are confusing. Couchbase-the-company was named back
>>> when
>>>>> it was very much about CouchDB, which then changed for complicated
>>>>> technical reasons. Couchbase Lite was originally called TouchDB, but
>>> was
>>>>> renamed for branding/marketing reasons outside my control.
>>>>> --Jens
>>>>> * CBL is missing some of the admin features, like user accounts and
>>>>> _restart, that don't make sense for an embedded database; and it adds
>>>>> couple of replication optimizations that I've been discussing on the
>>>>> 'replication' list here.

View raw message