incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gonzalez <gonva...@gonvaled.com>
Subject Re: Is the revision field deterministic?
Date Tue, 08 Apr 2014 11:44:19 GMT
Hi,

I have found the cause of the difference in the content: my libraries are
correcting some documents when reading from couchdb (to account for missing
properties in wrongly-structured documents). Some of those corrections are
using random-generated values, and that is why I am seeing a difference
when reading from one or another server.

The revision in couchdb is the same, and the content in couchdb is the
same, as expected.

Sorry for spamming the list.

BR,
Daniel


On Tue, Apr 8, 2014 at 1:00 PM, Daniel Gonzalez <gonvaled@gonvaled.com>wrote:

> Hi all,
>
> I have just seen a very intersting issue which I do not fullly understand.
> I have serverA and serverB, with the same replicated database db1.
>
> Sometimes replication is just turned off. Currently it is off.
>
> I have taken a look at a bunch of documents.and I have found a couple of
> them where the revision field is exactly the same, but the documents
> content is different. Since the content is different, that means those
> documents have not been replicated, but editted indepently in serverA and
> serverB.
>
> How could happen then that the revision field is the same? The only
> explanation that I can find is that the rev is derived from the document
> id, deterministically (together with the serial counter indicating the
> number of revision). But why would the revision be generated like that? I
> was under the impression that the revision was a random number (or "random
> enough"), so that cases like this (independent edition of a document) could
> be easily detected.
>
> So my question is: how is the revision field generated and, more
> importantly, makes my description of what is happening sense, or is there
> another explanation of why the rev field is the same? (I hope I am wrong!)
>
> Thanks and regards,
> Daniel Gonzalez
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message