On Thu, May 6, 2010 at 7:58 AM, Parker
<psei...@predictivetechnologies.com> wrote:
> I'm trying to port part of an existing application to Django. In the
> other application, each user has their data stored on separate
> databases with identical schemas.
>
> For example, if we have users A, B and C, there are 3 databases
> ("DatabaseA", "DatabaseB", "DatabaseC") each having two tables:
> blog_entries and blog_comments
>
> Ideally I'd like to write a single application into which all 3 users
> can login in. From here on out, all of the interactions with the
> database should be routed to database specific to that user. That is
> to say, UserA should only ever be able to insert and update data in
> DatabaseA and UserB should only be able to access DatabaseB.
>
> From a coding perspective, I'd like to leverage Django's multiple
> database support and implement this routing via the DATABASE_ROUTERS
> setting or as a ModelManager so that database I'm accessing abstracted
> away from the code. That is to say, I can write
> BlogEntries.objects.all() and always return only those blog entries
> for the currently authenticated user.
>
> Is this type of routing or model management possible with Django?
> Should I consider using a site-specific settings.py file simpler to
> what's discussed here:
> http://www.huyng.com/archives/franchising-running-multiple-sites-from-one-django-codebase-2/394/
What you're describing is "sharding" - splitting your database into
multiple shards, with each shard containing a subset of the full data
set. You should be able to write a sharding router that takes the hint
object information that is provided to the router, and use the pk of
the hint object to determine which shard should service the read and
write queries.
There are some complications in this; for example, finding a user in
the first place when you only know the username, but not the pk --
since the router will need a primary key to find the right shard,
you'll need to manually poll all the shards to find a user (unless
shard allocation is based on a hash of some other property of the user
object).
I would also point out that while this *should* be possible in theory,
it hasn't been the subject of extensive testing, so in practice, I
won't be surprised if you have difficulties. If you do, I'm certainly
interested in hearing any feedback and suggestions on modifications we
can make to accomodate sharding as a use case.
The "site specific settings" approach is a solution to a different
problem entirely. That's trying to cover the idea of having three
almost identical 'sites' with different frontend, but the same
backend. For example, consider a franchised news operation that runs a
news website for three cities; each city has the same news gathering
requirements, but the actual stories will be slightly different, and
the front end will need to be branded separately. Using site-specific
settings, you could run all three news sites out of the same machine,
the same database, and the same codebase, but maintain separate
appearance and content.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
