Ok, but does mean it is indeed related to the document content, so a
different content would produce a different revision number. In my case I
was having the same rev but different content, which is what I could not
understand (as explained, it was caused by my personal libraries)
And just curious: what does "the same content mean"? Is a different
re-ordering of the json fields still passing the comparisson check?
BR,
Daniel
On Tue, Apr 8, 2014 at 2:45 PM, Robert Samuel Newson wrote:
>
> I'll answer anyway.
>
> Yes, it's deterministic. The same document with the same history will have
> the same _rev value. This is an optimization over the previous algorithm
> where _rev was a random UUID. This changed years ago.
>
> The advantage is that two servers receiving the same update can more
> optimally replicate. They still have to check that the target has all
> _id/_rev pairs but will usually be able to skip actually transmitting
> document and attachment content.
>
> B.
>
>
> On 8 Apr 2014, at 12:44, Daniel Gonzalez wrote:
>
> > 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 >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
> >>
>
>