couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: The _security object should be versioned
Date Sat, 27 Aug 2011 20:46:02 GMT
On Sat, Aug 27, 2011 at 1:35 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Sat, Aug 27, 2011 at 12:05, Chris Anderson <jchris@apache.org> wrote:
>
>> On Sat, Aug 27, 2011 at 9:14 AM, Benoit Chesneau <bchesneau@gmail.com>
>> 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.


everything else sounds good to me. However I think we can go ahead and
make the _security doc have a _rev and MVCC, as most clients work on
it by load / edit / save anyway so this won't break compatibility. If
it turns out to be a problem we can rethink it.

Chris

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.
>



-- 
Chris Anderson
http://jchrisa.net
http://couchbase.com

Mime
View raw message