Yes, server admins. -Damien
On Mar 1, 2010, at 7:50 AM, Filipe David Manana wrote: > I assume your talking about server admins (those listed in the .ini file), > right? If you're talking about DB admins, than the problem is the same > (reading the _security object from each db file). > > On Mon, Mar 1, 2010 at 4:45 PM, Damien Katz <[email protected]> wrote: > >> I don't think end users need a list of dbs they can access on the server. >> Think the simplest answer is to only support _all_dbs operation for admins >> and be done. >> >> -Damien >> >> >> On Mar 1, 2010, at 1:40 AM, Brian Candler wrote: >> >>> 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. >> >> > > > -- > Filipe David Manana, > [email protected] > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men."
