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 Fri, 26 Aug 2011 22:58:23 GMT
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?

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.

-Randall

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