couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: /_all_dbs and security
Date Mon, 01 Mar 2010 09:40:00 GMT
On Mon, Mar 01, 2010 at 09:55:46AM +0100, Filipe David Manana wrote:
> > The reason for no storing _security as a doc is an optimization. So we
> > extend that optimization, and have something like a  security_changed event
> > for a db, that the _dbs database can react to. The model isn't different
> > from subscribing to _changes, it'd just be a separate code path.
> 
> That's a good idea (both simple and more efficient).
> 
> The only issues left are the cases where the user adds a new DB file
> (possibly coming from other server for e.g.) into the DB dir, deletes a DB
> file or replaces a DB file with an old version (a backup whose update seq
> number is from the past).
...
> Do you think this would add too much overhead or it could be a somewhat
> "light" approach? Or better, do you have a better idea for it?

Just as an idea, you could just turn this on its head. Suppose _dbs was the
primary source of information; then the _security record within the database
is just a cached copy of that.  It's easy enough to take a _changes feed
from _dbs to update this cache.

But in that case, the cache would be better kept in RAM, rather than within
the database file.

After all, CouchDB already keeps a cache of open database filehandles,
doesn't it?  So you could read the security information from a regular
document (an "expensive" operation) when you open the database, and then
just continue to use that version thereafter.  You'd invalidate the cache if
the corresponding _dbs object is updated.

However this leaves the following issue: what if the database file is
renamed on disk, or disk-copied to a different system which happens to have
an existing _dbs entry for that name?

I think the best solution is for the _dbs database to be indexed by uuid. 
But to make this work efficiently, the database file *on disk* should also
be named by its uuid, rather than the database name.  That's probably too
big a change to swallow at this stage.

But it does have some other side benefits (such as being able to "rename" a
database instantly without touching the filesystem, and being able to
automatically spread a large number of databases across directories without
forcing the user to use database names like 00/xxx, 01/yyy, 02/zzz etc)

Regards,

Brian.

Mime
View raw message