incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Is the revision field deterministic?
Date Wed, 09 Apr 2014 07:24:20 GMT

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.

B.

On 9 Apr 2014, at 01:26, Dale Harvey <dale@arandomurl.com> 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 <mark@hahnca.com> 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 <dale@arandomurl.com> 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 <jens@couchbase.com> wrote:
>>> 
>>>> 
>>>> On Apr 8, 2014, at 8:34 AM, Alexander Shorin <kxepal@gmail.com> wrote:
>>>> 
>>>>> 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 to
>>>> 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 a
>>>> couple of replication optimizations that I've been discussing on the
>>>> 'replication' list here.
>>> 
>> 


Mime
View raw message