couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Is it OK to interpret the generation count in a revision ID?
Date Tue, 12 Jul 2011 21:54:34 GMT
Revision IDs are documented as being opaque. They have changed in the
past and its not out of the question that they'll change in the

That said, there aren't any plans in the works that I'm aware of that
will change these drastically. I have called for them to be changed
(in an indirect way) but even so I don't see this change happening any
time soon.

In this particular case, I'm not sure if we even document that the
revs=true option exists, as I can't think of where it would be used
outside the replicator so even the format of this response might be
subject to change.

To your other question, I'm not entirely certain what you mean about
ordering here. Are you wanting to ask whether one revision is a
derivative of another to get some idea on the document update order?
If so that's playing loose and fast with some replication internals
that might work but I don't think we'd treat this as something that's
part of any public API at the moment.

At some point in the future it would be nice if we could sit down and
document and version our replicator protocol, but that would be a
siginificant amount of work that's never been attempted.

On Tue, Jul 12, 2011 at 4:26 PM, Jens Alfke <> wrote:
> I’ve been assuming that document revision IDs are opaque, that the generation count
prefix (“1-“, “2-“, etc.) is purely for troubleshooting. (I think I asked about this
> But now I see that the _revisions array returned with a document (with a “?revs=true”
query string) removes those generation prefixes and requires you to re-attach them to generate
useable revision numbers:
> $ curl '’
>   ...
>   "_revisions”: {
>       "start":3,
>       "ids”: [
>           "b613f5db612d6280d11c358ff9d073a7",
>           "fe117f9b71157a03ce8aaa6b49fdf73d",
>           "99eb6af272f7d854e55ff80c0b475fa9"
>       ]
>   }
> In other words, the actual revision IDs are
>        “3-b613f5db612d6280d11c358ff9d073a7”,
>        “2-fe117f9b71157a03ce8aaa6b49fdf73d”,
>        “1-99eb6af272f7d854e55ff80c0b475fa9”
> so to get those I have to add code to iterate the “ids” array and prepend the generation
number to each string.
> Given that this format is baked into the protocol, may I rely on it for other purposes?
It would be very useful to be able to look at two revision IDs and determine some (partial)
ordering. I’m aware that conflicts mean that there’s no true ordering, but partial is
better than nothing.
> —Jens

View raw message