On Thu, Aug 25, 2011 at 8:55 PM, Jason Smith <j...@iriscouch.com> wrote:
> On Fri, Aug 26, 2011 at 8:59 AM, Paul Davis <paul.joseph.da...@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
