On Aug 26, 2011 4:31 PM, "Paul Davis" <paul.joseph.da...@gmail.com> wrote: > > 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.
That's what I suspected. Progress! > 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. Totally agree. I don't want to special case _design/security, so if it goes anywhere I vote for a _local doc. > > 2 is a completely different issue and IMO has nothing to do with this thread. I think there are arguments for 2, but it's another thread and I think the motivation is unique to the vanilla clustering case (Lounge). > > 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. Agree. I don't even think we need to surface the MVCC API, though (unless we want to, but I'm conservative when it comes to API surface area). > > > 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. _local docs already do. They just don't support ?new_edits, or revs_info/revs/open_revs/meta, though I'd have to check.. It's not a hard requirement that we support this stuff. And certainly the old /_security endpoint could completely paper over this if we just make it clobber (which no one on vanilla couch should care about).
