couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: The _security object should be versioned
Date Sun, 28 Aug 2011 23:35:58 GMT
On Aug 27, 2011 5:38 PM, "Adam Kocoloski" <kocolosk@apache.org> wrote:
>
> On Aug 27, 2011, at 5:19 PM, Paul Davis wrote:
>
> > On Sat, Aug 27, 2011 at 3: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. 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

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