couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: The _security object should be versioned
Date Sun, 28 Aug 2011 00:38:11 GMT
On Aug 27, 2011, at 5:19 PM, Paul Davis wrote:

> On Sat, Aug 27, 2011 at 3:35 PM, Randall Leeds <> wrote:
>> 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.
> 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".

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,

View raw message