couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: The _security object should be versioned
Date Sat, 27 Aug 2011 02:19:43 GMT
On Fri, Aug 26, 2011 at 9:09 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> 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).
>

Not necessarily a clustering issue at all. Some people are using the
non-replication semantics of _local docs to store node local
information which is fine. I've seen a couple requests to expose an
_all_local_docs or similar so they can list their node information
easily.

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

I'm not entirely certain about not having the MVCC semantics public on
this one. I'd lean towards it being necessary but it seems like
something that could be worked around internally for people that care.

Mime
View raw message