Why do you need this for DB-Admins? Is that an application-level
requirement?
Why don't maintain those informations in an extra database?
greetz
mario
Am 01.03.2010 um 16:50 schrieb Filipe David Manana:
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."
--
Sourcegarden GmbH HR: B-104357
Steuernummer: 37/167/21214 USt-ID: DE814784953
Geschaeftsfuehrer: Mario Scheliga, Rene Otto
Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
Schoenhauser Allee 51, 10437 Berlin
