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 Fri, 26 Aug 2011 21:55:55 GMT
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.

Paul I am not sure which way to go on the does-it-replicate thing for
security docs.

If we want to put security in a regular doc for ease of cluster
replication, the _design namespace already has the proper security
policy (admin only), so it could live at _design/security (aliased
also to _security for backwards compatibility for 1.x)

But I think an expectation is that they would not replicate, so it
makes me think it should live in a _local doc with _local mvcc, and a
cluster manager's script is to update the security object(s) around
the cluster correctly. This is not transactional so it make sense to
give a user some status updates on security changes ("updated security
for 22 of 36 shards.")

Chris

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

Mime
View raw message