Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: /_all_dbs and security
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Damien Katz <damien@apache.org>
In-Reply-To: <20100301094000.GA4798@uk.tiscali.com>
Date: Mon, 1 Mar 2010 07:45:36 -0800
Cc: fdmanana@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <F943741E-30FE-469D-B0FC-E0B1F6A4A6BF@apache.org>
References: <cadf1c691002271032l13f415a2t58ca76f42ce3cfa5@mail.gmail.com>
 <7C5AB910-A94E-411A-8D81-0E5C33F28FEB@gmail.com>
 <cadf1c691002280742h5c91fe47vd91a555400dd1b1e@mail.gmail.com>
 <5AAAEEB4-828A-4D56-A4D5-AF4DA84A26F2@gmail.com>
 <cadf1c691003010055p59af264i4d2643d70955895c@mail.gmail.com>
 <20100301094000.GA4798@uk.tiscali.com>
To: dev@couchdb.apache.org

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.
>>=20
>> That's a good idea (both simple and more efficient).
>>=20
>> 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?
>=20
> 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.
>=20
> But in that case, the cache would be better kept in RAM, rather than =
within
> the database file.
>=20
> 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.
>=20
> 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?
>=20
> I think the best solution is for the _dbs database to be indexed by =
uuid.=20
> 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.
>=20
> 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)
>=20
> Regards,
>=20
> Brian.