On Fri, Aug 26, 2011 at 5:58 PM, Randall Leeds <randall.le...@gmail.com> wrote: > On Aug 26, 2011 2:56 PM, "Chris Anderson" <jch...@apache.org> wrote: >> >> On Thu, Aug 25, 2011 at 8:55 PM, Jason Smith <j...@iriscouch.com> wrote: >> > On Fri, Aug 26, 2011 at 8:59 AM, Paul Davis <paul.joseph.da...@gmail.com> > wrote: >> >> I wouldn't focus on the _local docs suggestion too much. >> > >> > I proposed a _local doc to keep couch simple and self-similar; and at >> > the time I incorrectly thought that _local docs had full revision >> > support. >> > >> > I wish db/_security would become db/_local/security to trim down the >> > API surface area. Clients could re-use their doc updating code to set >> > a security policy. >> >> An easy way to benchmark this is to hardcode a local doc lookup to >> every db open call and see if it makes things slower. Also can compare >> with a regular doc lookup. >> >> Probably these differences matter more when you are highly concurrent >> and near swap, especially if you have lots of databases open on >> virtualized io. > > It's probably safe to wear meat around your neck. You could test this by > hanging a steak on a chain and walking around your house. Probably it > matters more if you're out in the woods at night, surrounded by wolves, and > have a broken leg. > > ;) > >> >> Paul I am not sure which way to go on the does-it-replicate thing for >> security docs. > > I think we're conflating 'does replicate' with 'does have an associated > seq'. However, 'doesn't have a seq' != 'doesn't have a rev tree'. On a > single node the latter is an optimization. On a cluster, the latter is > necessary for properly dealing with gross, gross edge cases caused by the > ubiquity requirement on _design documents (for views), _security (for, uh, > security), and possibly _local (for highly available external replication > checkpoints). > > Keep in mind, the replicator is not special, it's just one way to surface > the deeper APIs toward the goal of syncing documents. > > The two important/valid questions worth asking: > 1) Should changes to _security surface in _changes? > 2) Should the _local docs collection be querable? > 3) Should docs without a seq still have a rev tree? >
1) No. 2) Yes. 3) The actual question. In no way should the security object even approach the possibility of replication. Think of all the poor phones that accidentally download a _design/security doc that locks them out of their own data. 2 is a completely different issue and IMO has nothing to do with this thread. This entire thread was supposed to be about 3 but has predictably wandered off into the weeds. The question about moving these security objects around is what to do when they diverge. If we give them a revision tree and give it an MVCC API at the HTTP level then it becomes much easier to deal with in the common case. Granted there are corner cases like "what do with do with a conflict?" Which IMO could be left undefined in the Apache CouchDB API cause it couldn't happen. > I think the answer to 3 is yes. I think a negative answer to 1 mandates hard > thinking about 2 or else the clustering software or operator is blind in her > attempts to synchronize these special-purpose documents. > > In vanilla Apache CouchDB I'm fine if the docs don't have a seq, but to make > patching for forks like BigCouch easier I'm going to spend a little time > refactoring the rev tree merging code to be oblivious as to where the rev > trees come from and whether the docs have sequence numbers. That part > shouldn't be bad and arguably the rest is left to the authors of the > clustering fork. The issue here is that adding a revision tree most likely means a requirement that the HTTP API changes to use MVCC tokens.
