Merge pull request #13 from jaypipes/master

Add UserKeyResource to API
Adds support for slug fields

Enhances the User model first, adding a user_name
column as well as a new slug column, slugified automatically
from user_name's value.

In order to reduce duplication of code and keep things DRY,
this patch adds a decorator that can be placed on any DB API
call that follows the get_$model_by_pk() pattern. This decorator
adapts the decorated function to look at the value of the supplied
primary key lookup value, and if the value does **not** look like
a UUID, then the decorator presumes it is a slug, and attempts to
look up the real primary key based on the slug.

This allows any model that has a slug attribute on it to be
looked up by primary key as well as the easier to understand and
remember slug value. Since the integration is entirely in the database
API, this means that any REST API call that has the pattern:

GET|PUT|DELETE /$model/{model_id}

will work just as well using a slug for {model_id} as a UUID.
Merge pull request #14 from jaypipes/slugs

Adds support for slug fields
Add sharded organization model using nested sets

The world-view of Procession is divided into Organizations,
Users, and Groups. Organizations are simply containers for Users
Organizations. Groups are containers for Users within an
Organization that are used for simple categorization of Users. Groups have
a set of Roles associated with them, and Roles are used to indicate
the permissions that Users in the Group having that Role are assigned.

Organizations that have no parent Organization are known as Root
Organizations. Each Organization has attributes for both a Parent
Organization as well as the Root Organization to which the
Organization belongs. This allows us to use both an adjacency list model for
quick immediate ancestor and immediate descendant queries, as well as a nested
sets model for more complex queries involving multiple levels of the
Organization hierarchy.

We use multiple Root Organizations in order to minimize the impact of
updates to the Organization hierarchy. Since updating a nested sets
model is expensive -- since every node in the hierarchy must be updated to
change the left and right side pointer values -- dividing the whole
Organization hierarchy into multiple roots allows us to have a nested
set model per Root Organization, which limits updates to just the
Organizations within a Root Organization. If we used a single-root tree, with all
Organizations descendents from a single Organization with no parent, then
each addition or removal of an Organization would result in the need to
update every record in the organizations table.
Merge pull request #15 from jaypipes/orgs

Add sharded organization model using nested sets