couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: format of database sequence
Date Tue, 26 Oct 2010 20:19:15 GMT
On Tue, Oct 26, 2010 at 3:23 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Tue, Oct 26, 2010 at 3:06 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> I don't see any way to avoid this and we've been talking about it for a while.
>> +1
>>
>> On Tue, Oct 26, 2010 at 11:59, Adam Kocoloski <kocolosk@apache.org> wrote:
>>> Hi all, I've been meaning to bring this up for a while.  CouchDB uses integer
sequence numbers in the _changes feed and update_seq values, but I don't see any sensible
way to preserve that interface in BigCouch.  The database sequence in BigCouch needs to combine
the sequences of several database shards; currently it's a string formatted like
>>>
>>> "1234-Base64Data"
>>>
>>> The first piece is the sum of the shard sequence numbers and is not actually
used by BigCouch.  The second piece is the actual data about the state of the cluster.  This
format causes a couple of issues:
>>>
>>> 1) the replicator occasionally sorts sequence numbers and when it does so, it
sorts the BigCouch ones lexicographically and concludes that e.g. "99-..." is the only checkpoint
it will ever need to store.
>>>
>>> 2) client libraries might not treat the sequence as an opaque data type and may
break when operating against a BigCouch.
>>>
>>> My personal preference would be to change the format of the Apache CouchDB sequence
to a string at the next major release.  Thoughts?
>>>
>>> Adam
>>>
>>>
>>
>
> Is there a possibility to retain a guarantee of triangle inequality
> for update sequences? In my experience people are mostly using them to
> detect an ordering. It seems like if we could give a loose ordering,
> that'd be better than just an opaque type. Though, I'm also not sure
> how that'd work in relation to string comparison operators in most
> languages.
>
> I'm +1 on the switch, I'm just wondering if we can do it without
> making them completely opaque.
>
> Paul Davis
>

I've since been informed that not only do I have no idea what I'm
talking about, that its also not possible. So I stand at +1 for an
opaque string. To make up for the noise I'll include a link:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/6a16efa375532182

Paul Davis

Mime
View raw message