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.
