On Tue, Dec 27, 2011 at 05:22, Jason Smith <j...@iriscouch.com> wrote: > On Tue, Dec 27, 2011 at 5:04 AM, Randall Leeds <randall.le...@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
