couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.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 Wed, 28 Dec 2011 02:38:30 GMT
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:
>> Either
>> these things have a proper place in the sequential history of a
>> database or they do not. That there are things which affect update_seq
>> but do not appear in the by_seq index and _changes feed feels like a
>> mistake.
>
> The first sentence is, well, a tautology actually, but it asks the
> right question and the answer is they DO NOT belong. _changes shows
> data, not metadata. By definition, _changes is anything worth
> replicating.

That strikes me as incorrect. The _changes feed is purely metadata
unless ?include_docs=true is specified.

>
> But I hope my filesystem example above shows why it is okay to
> increment update_seq but not change by_seq.

You show a nice precedent for separating metadata and data, but
CouchDB has a decent precedent of avoiding this same thing. For
example, _id and _rev are in the returned document body rather than
part of the HTTP request (it could have been just URL and entity tag
headers only for this).

>
> The bug with update_seq is not that it it is too eager (increments for
> _security, _revs_limit), but it is not eager enough (it should bump
> for _local too).
>

I agree, but for different reasons. I think _local docs may have a
place in by_seq even if the default _changes request still only shows
the default, replicable documents.

> 2. As a frequent consumer of _changes, I would prefer *not* to see
> _local documents, nor _security or other updates in there. They are
> metadata, not data. Maybe I misunderstood, but nobody wants to
> *replicate* _security objects or _local docs; they just want MVCC
> semantics (Adam on _security, IIRC) and a simplified API (me, on
> making all metadata a _local doc, and making _local docs full MVCC).

I think you misunderstand, maybe. In the case of BigCouch, MVCC is all
that's needed because the replication does not go over HTTP. I see no
reason to require that special care be taken to copy these objects
when a flag on the _changes feed might cause them to be transferred
very naturally. In particular, I would use this feature in a
hypothetical Lounge 3.0. It also means that with admin privileges we
could do full backup replications.

-R

Mime
View raw message