couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: The _security object should be versioned
Date Sat, 27 Aug 2011 20:35:15 GMT
On Sat, Aug 27, 2011 at 12:05, Chris Anderson <> wrote:

> On Sat, Aug 27, 2011 at 9:14 AM, Benoit Chesneau <>
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message