On Tue, Dec 27, 2011 at 22:37, Jason Smith <j...@iriscouch.com> wrote: > On Wed, Dec 28, 2011 at 9:38 AM, Randall Leeds <randall.le...@gmail.com> > wrote: >> 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: > 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. Granted, app developers don't need to know anything about the by_seq tree, but I don't see a compelling reason to keep the old definition of update_seq. 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 ctime. > Is it really true that shards need the same _revs_limit as the > simulated whole? Maybe they really want _revs_limit / > number_of_shards? > > Is it really necessary that _security be identical in each shard? > Actually, yes it is, because validate_doc_update uses it. But still... > > How are you computing doc_count in the /db response? You have to sum > doc_count from each shard. But every shard needs a copy of every > design doc for validation. So you have to subtract those back out? My > broader point is, sharding applications already do lots of magic. I'm > not sure if replicating _security and _local docs buys you much. Good observations as well. -Randall
