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.
