On Aug 27, 2011 5:38 PM, "Adam Kocoloski" <[email protected]> wrote: > > On Aug 27, 2011, at 5:19 PM, Paul Davis wrote: > > > On Sat, Aug 27, 2011 at 3:35 PM, Randall Leeds <[email protected]> wrote: > >> On Sat, Aug 27, 2011 at 12:05, Chris Anderson <[email protected]> wrote: > >> > >>> On Sat, Aug 27, 2011 at 9:14 AM, Benoit Chesneau <[email protected]> > >>> wrote: > >>> > >>>> _security doc or object is something we need available each time we open > >>> a > >>>> db thoug. So having it in db headers has a lot of sense imo. If it's > >>> savd > >>>> with #full_doc_* semantic does it means it will be saved in the db, and > >>> we > >>>> keep a pointer to it in the db header ? Or would it still be saved in the > >>> db > >>>> header? > >>>> > >>>> > >>>> - benoit > >>>> > >>> > >>> Currently a pointer to it is stored in the db header. The pointer > >>> could be to whatever, wouldn't change things. So if full_doc_info > >>> solves the original question, that works for me. > >>> > >>> I think for 2.0 we should consider whether to move it to a _local/doc > >>> or not. Part of the point of the original implementation is > >>> simplicity. If it stops being simple we should feel free to refactor > >>> as long as we don't break people's expectations. > >>> > >> > >> > >> How's this for a way forward? > >> > >> 1) Refactor couch_db_updater:merge_rev_trees so that the action of merging a > >> revision tree is decoupled from the maintenance of the by_seq index. In > >> particular, I would love to see a function which just merges a single > >> document's revision tree. That code can be re-used for folding over all the > >> regular document updates that affect the _changes/by_seq index and also used > >> for the _security object. > >> > >> 2) Promote _security to a #full_doc_info record. Keep a pointer to it in the > >> db header still. Write the upgrade code. > >> > >> 3) Let the current _security API stay as it is (it has to until 2.0, > >> right?), with clobbering/auto-rev-bump semantics. This is not so different > >> from the case of regular document creation, where we treat it as an implicit > >> update to the {0, []} revision. That should make incomplete updates to a > >> cluster-wide _security object resolvable for fork maintainers (I'm looking > >> at you, Paul). > >> > >> 4) Bump any discussion of an explicit MVCC API at the HTTP level for > >> _security and all discussion of _local docs to another time/thread. > >> > > > > Yes to all of this except bumping MVCC HTTP discussion. I haven't yet > > convinced myself that its doable without exposing the standard _rev > > semantics to clients. And as Chris mentions it'd probably already fit > > into most people's current update patterns. It does seem like there's > > a possibility to hide it from clients but I'm not sure that's > > appropriate here. > > For what it's worth, I'd prefer to upgrade the _local tree to use #full_doc_info records, store the security object as a document in the _local tree (but cache it when the #db is first opened), and preserve the current _security API with "clobbering/auto-rev-bump semantics". >
That works for me. As a bonus, we can put it in that tree but leave it called _security and none of the HTTP paths will ever access it (since it doesn't start with _local/), so we won't have to rework all the access controls on it. > Storing the security object as a #full_doc_info external to any tree is also OK, but I'm confident the ability to store divergent histories will be generally useful for _local documents in a cluster. Best, > > Adam I am, too, but Paul gets mad at me when I expand the scope of a thread ;). I'm about to sign off technology for a week, but I'll happy start writing this when I return if no one's picked it up. Can we get a JIRA ticket for it? -Randall
