On Tue, Mar 10, 2009 at 12:21 PM, Adrian Holovaty <adr...@holovaty.com>wrote:
>
> I'm working on adding multiple-database support to an application and
> am building a custom manager that lets me specify which DATABASE_NAME
> to use for a particular model. It looks something like this:
>
> class OtherDatabaseManager(models.Manager):
> """
> This Manager lets you set the DATABASE_NAME on a per-model basis.
> """
> def __init__(self, database_name, *args, **kwargs):
> models.Manager.__init__(self, *args, **kwargs)
> self.database_name = database_name
>
> def get_query_set(self):
> qs = models.Manager.get_query_set(self)
> qs.query.connection = self.get_db_wrapper()
> return qs
>
> def get_db_wrapper(self):
> from django.db.backends.postgresql_psycopg2.base import
> DatabaseWrapper
>
> # Monkeypatch the settings file. This is not thread-safe!
> old_db_name = settings.DATABASE_NAME
> settings.DATABASE_NAME = self.database_name
> wrapper = DatabaseWrapper()
> wrapper._cursor(settings)
> settings.DATABASE_NAME = old_db_name
> return wrapper
>
> class MyModel(models.Model):
> # ...
> objects = OtherDatabaseManager('my_custom_database)
>
> This is not unlike the code here:
> http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
> --
>
> One ugliness about this is that it has to monkeypatch the settings
> file in order to change the DATABASE_NAME, before passing it to
> DatabaseWrapper._cursor(). So my proposal is to change
> DatabaseWrapper._cursor() to accept a settings *dictionary* instead of
> a settings *object*.
>
> The only place in the Django codebase that calls
> DatabaseWrapper._cursor() is BaseDatabaseWrapper.cursor() in
> db/backends/__init__.py. That, plus the fact that this method name is
> preceded by an underscore, leads me to believe there are no
> backwards-incompatibility issues with making this change. But I'm
> bringing it up here in case anybody wants to point out problems before
> I commit it.
>
> Adrian
>
> >
>
I've been looking at adding multiple database support to Django for a little
while now and as a part of my plan of action the first step is to remove all
references to the global settings in django.db.backends.* and replace them
with a settings dict as you suggest(minus stuff like settings.DEBUG
obviously). My proposal goes a little further than yours however since I
propose passing the settings dict in into the constructor of the connection
itself, not in the _cursor method, the advantage here is that when we create
the connection we have all the information we need then.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
