Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <319C03F7A120754B9128CF308BF5E0370308FF05@nasa-dtw-ex004.nasa.cpwr.corp>
References: 
 <319C03F7A120754B9128CF308BF5E0370308FF05@nasa-dtw-ex004.nasa.cpwr.corp>
Date: Tue, 27 Oct 2009 23:04:02 +0000
Message-ID: <30b2aef60910271604i2da2a7e2ma189510e07923ef1@mail.gmail.com>
Subject: Re: How Do You Model This?
From: Leo Simons <mail@leosimons.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 27, 2009 at 8:07 PM, Welch, Matt <Matt.Welch@compuware.com> wrote:
> [sample users, groups, directory]

Data model (some of it summary, some of it assumptions):
* A user is identified by a name.
* A user is a member of 0 or more groups.
* A group is identified by a name.
* A directory is identified by a name.
* A group has access to 0 or more directories.

There are probably more directories and more users than there are
groups. Adding and removing directories is probably the most frequent,
following by adding and removing users, followed by adding and
removing groups.

Turn into documents:
* Make a document per user.
* The user document lists the user's groups.
* Make a document per directory.
* The directory document lists the groups that have access to it.
(It seems like you wouldn't need a document for a group, a group
simply exists as long as the name exists in any document as a string.)

Implications:
* Adding and removing users is easy. Adding and removing users from
groups is easy.
* Adding and removing directories is easy. Adding and removing
permissions to directories is easy.
* Adding groups is implicit (which you may not like). Removing groups
is hard (which you may like even less).

Querying:
* To find all the things that a user has access to, first get the
user's document and the list of groups from it. Then, do a map/reduce
over all directories, where you emit only directories that have at
least on group that is in the users group list. You can make that a
view :)
* To find a full list of permissions, do a two-step map/reduce. I
think you can also make that a view in couch :)

Eventual consistency considerations:
* in a distributed scenario, you may wish to have something like a
group_delete_list, which is a document that is used as a special
filter for groups that are pending deletion. You'll have to make your
views respect it, or do that inside application code.

> Then I want to look up what directories Alice has permissions to, or
> even make a master list of all the users and their permissions like
...
> I need to do the equivalent of adding and removing users, adding and
> removing directories, and change group and permission assignments. None
> of that can be static.

That seems possible with the above.

> So how do I set up my data and views in CouchDB to do this kind of
> thing? Or is this just not the sort of thing CouchDB will be good at
> modeling?

Frankly, this kind of model is something that a relational database is
*exceedingly* good at. If you need to do it on a really large scale, a
tree structure (LDAP...) is the way to go. I'm sure CouchDB can be
made to work for this kind of thing just fine, but some of it will be
more awkward.

ciao,

Leo