> The nice thing about the current comparisons is that they are made > in-memory, with no db access necessary to perform them.
I was imagining that this sort of thing would be cached the first time that you touch a particular database. But I can see that involves work, because of the stateless nature of couchdb. After all, we're not a SQL database with a client connection :-) > Documents are great for application level functionality. But when we > are talking about db-prefs (admins and readers) it makes things more > predictable that they don't replicate. If it's desirable that these things *don't* replicate, then I propose the following instead. (1) User has a role "dbname:_admin" if they're a database administrator, and "dbname:_reader" if they're a reader. (2) That's it. I make the following observations: * We already must know the roles associated with this user, so the checking is cheap * It scales (N users each with access to M databases) * It doesn't have concurrency issues * It doesn't involve a special API nor changes to the on-disk format * It easily supports the idea of a separate "db:_manager" role (who can add and remove users to a database, except for _admins) Now, we want world-readable databases too. I suggest the simplest thing there is to have a user whose name is "_anon", and every time you create a database you add it as a reader on that user (unless you ask for a private database). A user who is not logged in gets the roles of _anon instead. There is one huge advantage here. When a user queries _all_dbs you can immediately return only the list of databases that they have access to (just from their user record plus the _anon user record). Even if you have a million databases, but this user has only access to 20 of them, you can show those 20 without having to do a full disk scan. (The system-level _admin user would do the normal database scan still) > Again, the only way to scale this design to large #s of user accounts, > is to keep the user accounts in the per-server users db Then let's use a scalable way from the start. Regards, Brian.
