couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: [jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
Date Thu, 29 Dec 2011 00:21:37 GMT
On Thu, Dec 29, 2011 at 1:44 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 22:37, Jason Smith <jhs@iriscouch.com> wrote:
>> On Wed, Dec 28, 2011 at 9:38 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>>> On Tue, Dec 27, 2011 at 05:22, Jason Smith <jhs@iriscouch.com> wrote:
>>>> On Tue, Dec 27, 2011 at 5:04 AM, Randall Leeds <randall.leeds@gmail.com>
wrote:
>> Your idea improves consistency and orthogonality. It also solves the
>> problem of how to enumerate _local docs. (AFAIK there is no way to
>> list them all, not via _all_docs, or _changes, or a view).
>>
>> But it doesn't solve the larger problem: How to follow a _changes feed
>> and know when you have caught up. Both Bob N. and I independently did
>> the following for our projects:
>>
>> 1. GET /db and wrongly assume update_seq will appear in the changes feed
>> 2. GET /db/_changes?feed=continuous
>> 3. Break when a change has .seq >= update_seq
>>
>> Suppose you have step 0: Update _security or _revs_limit. The loop
>> will never break.
>>
>> You propose (WLOG) _changes?comprehensive=true which guarantees a
>> change equal or greater than update_seq. That's cool, but IMO app
>> developers now have to add code to ignore irrelevant changes like
>> those containing replication checkpoints.
>
> All great points.
>
>>
>> I propose (WLOG) update_sikh in the db header which is the seq id of
>> the latest *document* update. App developers modify their step 1 to
>> use update_sikh instead of update_seq.
>>
>> Is that an accurate synopsis?
>
> Yes. If we decide to go this route I would rather see _revs_limit and
> _security stop bumping update_seq because I find it confusing that
> update_seq is then not directly related to the by_seq tree.

"update_seq is not directly related to the by_seq tree." That is a
very powerful observation. My idea has less orthogonality and
conceptual simplicity.

The only mystery is why update_seq did this in the first place. Did
Damien have a reason, from hard-won experience?

> The one exception raised so far is your observation that
> it may be useful for doing backups. However, if that's the only real
> exception, perhaps we should surface some other thing more directly
> analogous to the UNIX crime.

Meh, the backups argument is okay, but weak. If you depend on it,
you'll miss _local docs (replication checkpoints, so that's no small
error). You still have to back up .ini files, and perhaps logs and
view files. So my suggestion for Unix crime is just that: OS
timestamps.

-- 
Iris Couch

Mime
View raw message