2009/3/14 Adrian Holovaty <adr...@holovaty.com>
>
> I've been trying to get a multiple-database setup working with Django.
> Thanks to some trunk changes from the past few days (not to mention
> all of Malcolm's work with queryset-refactor, etc.), doing SELECTs
> from multiple databases is now pretty easy -- and I'd even call it
> "clean"! But INSERTs, UPDATEs and DELETEs are still a pain, mostly due
> to Django's transaction management infrastructure.
>
> In exploring this, I've realized that Django's transaction management
> needs to be refactored to get multiple-database support working. BUT,
> if we do it right, we have an opportunity to simplify our transaction
> APIs at the same time. I have never liked our transaction APIs --
> requiring decorators? WTF? -- so I have long waited for the day when
> we can clean it up and make it into something that I actually enjoy
> using (and don't have to look up in the documentation each time I want
> to use it).
>
> So I have a proposal. Here are the main design concepts:
>
> * Django manages a set of connections, accessible either via a global
> dictionary (maybe django.db.connections) or some API
> (django.db.get_connection()). This is what we've been talking about in
> the "More multi-database plumbing" thread on django-developers.
>
> * Connections are specified in the settings file. Each connection has
> a label, like "default", "auth", whatever.
>
> * Transactions are managed via methods on connection objects. NOT via
> some strange decorator and magic global django.db.transaction variable
> that comes out of thin air.
>
> * QuerySets (and likely model objects, too) have hooks for
> *optionally* specifying which connection to use in their queries.
>
> * We retain the concept of a "default" connection, which is the key
> for making this backwards-compatible and easy to use.
>
> Here's some example code:
>
> """
> from django import db
> from mysite.users.models import User
>
> # This updates User objects on the default connection with
> # auto-commit.
> User.objects.update(is_registered='t')
>
> # This updates User objects on the "auth" connection with
> # auto-commit.
> User.objects.with_connection("auth").update(is_registered='t')
>
> # This is equivalent to the previous example, demonstrating
> # that with_connection() also can take a connection object.
> conn = db.get_connection('auth')
> User.objects.with_connection(conn).update(is_registered='t')
>
> # This updates User objects on the default connection within
> # a transaction.
> conn = db.get_connection() # Equivalent to get_connection('default')
> conn.begin()
> User.objects.update(is_registered='t')
> conn.commit()
>
> # This updates User objects on the "auth" connection within
> # a transaction.
> conn = db.get_connection('auth')
> conn.begin()
> User.objects.with_connection(conn).update(is_registered='t')
> conn.commit()
> """
>
> For backwards compatibility, we can still keep the legacy decorators
> -- transaction.commit_on_success(), etc. -- and they'd just work on
> the default connection. But we'd encourage people to use this new API.
>
> My proposal is not necessarily to get this in Django 1.1, but to get
> it in trunk at the very least. I'm selfishly motivated by my own
> project to get this done ASAP, so I'm very happy to do the
> development.
>
> Adrian
>
> >
>
What about having an attribute in the Meta class of the model that let's the
model have a default connection for executing the 4 most common different
operations in each conneciton, something like
class MyModel(models.Model)
class Meta:
select_conn = "default"
insert_conn = "write_conn"
update_conn = "write_conn"
delete_conn = "write_conn"
This would make it easy to use Django in a single-master/multi-slave
scenario.
--
http://blog.cuerty.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
