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 Sat, 27 Aug 2011 02:09:40 GMT
On Aug 26, 2011 4:31 PM, "Paul Davis" <paul.joseph.davis@gmail.com> wrote:
>
> On Fri, Aug 26, 2011 at 5:58 PM, Randall Leeds <randall.leeds@gmail.com>
wrote:
> > On Aug 26, 2011 2:56 PM, "Chris Anderson" <jchris@apache.org> wrote:
> >>
> >> On Thu, Aug 25, 2011 at 8:55 PM, Jason Smith <jhs@iriscouch.com> wrote:
> >> > On Fri, Aug 26, 2011 at 8:59 AM, Paul Davis <
paul.joseph.davis@gmail.com>
> > wrote:
> >> >> I wouldn't focus on the _local docs suggestion too much.
> >> >
> >> > I proposed a _local doc to keep couch simple and self-similar; and at
> >> > the time I incorrectly thought that _local docs had full revision
> >> > support.
> >> >
> >> > I wish db/_security would become db/_local/security to trim down the
> >> > API surface area. Clients could re-use their doc updating code to set
> >> > a security policy.
> >>
> >> An easy way to benchmark this is to hardcode a local doc lookup to
> >> every db open call and see if it makes things slower. Also can compare
> >> with a regular doc lookup.
> >>
> >> Probably these differences matter more when you are highly concurrent
> >> and near swap, especially if you have lots of databases open on
> >> virtualized io.
> >
> > It's probably safe to wear meat around your neck. You could test this by
> > hanging a steak on a chain and walking around your house. Probably it
> > matters more if you're out in the woods at night, surrounded by wolves,
and
> > have a broken leg.
> >
> > ;)
> >
> >>
> >> Paul I am not sure which way to go on the does-it-replicate thing for
> >> security docs.
> >
> > I think we're conflating 'does replicate' with 'does have an associated
> > seq'. However, 'doesn't have a seq' != 'doesn't have a rev tree'. On a
> > single node the latter is an optimization. On a cluster, the latter is
> > necessary for properly dealing with gross, gross edge cases caused by
the
> > ubiquity requirement on _design documents (for views), _security (for,
uh,
> > security), and possibly _local (for highly available external
replication
> > checkpoints).
> >
> > Keep in mind, the replicator is not special, it's just one way to
surface
> > the deeper APIs toward the goal of syncing documents.
> >
> > The two important/valid questions worth asking:
> > 1) Should changes to _security surface in _changes?
> > 2) Should the _local docs collection be querable?
> > 3) Should docs without a seq still have a rev tree?
> >
>
> 1) No.
> 2) Yes.
> 3) The actual question.

That's what I suspected. Progress!

> In no way should the security object even approach the possibility of
> replication. Think of all the poor phones that accidentally download a
> _design/security doc that locks them out of their own data.

Totally agree. I don't want to special case _design/security, so if it goes
anywhere I vote for a _local doc.

>
> 2 is a completely different issue and IMO has nothing to do with this
thread.

I think there are arguments for 2, but it's another thread and I think the
motivation is unique to the vanilla clustering case (Lounge).

>
> This entire thread was supposed to be about 3 but has predictably
> wandered off into the weeds. The question about moving these security
> objects around is what to do when they diverge. If we give them a
> revision tree and give it an MVCC API at the HTTP level then it
> becomes much easier to deal with in the common case. Granted there are
> corner cases like "what do with do with a conflict?" Which IMO could
> be left undefined in the Apache CouchDB API cause it couldn't happen.

Agree. I don't even think we need to surface the MVCC API, though (unless we
want to, but I'm conservative when it comes to API surface area).

>
> > I think the answer to 3 is yes. I think a negative answer to 1 mandates
hard
> > thinking about 2 or else the clustering software or operator is blind in
her
> > attempts to synchronize these special-purpose documents.
> >
> > In vanilla Apache CouchDB I'm fine if the docs don't have a seq, but to
make
> > patching for forks like BigCouch easier I'm going to spend a little time
> > refactoring the rev tree merging code to be oblivious as to where the
rev
> > trees come from and whether the docs have sequence numbers. That part
> > shouldn't be bad and arguably the rest is left to the authors of the
> > clustering fork.
>
> The issue here is that adding a revision tree most likely means a
> requirement that the HTTP API changes to use MVCC tokens.

_local docs already do. They just don't support ?new_edits, or
revs_info/revs/open_revs/meta, though I'd have to check.. It's not a hard
requirement that we support this stuff. And certainly the old /_security
endpoint could completely paper over this if we just make it clobber (which
no one on vanilla couch should care about).

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