On Sep 10, 12:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> For those who weren't at DjangoCon, here's the state of play with
> regards to multi-db support: Django actually supports multiple
> database connections right now: the Query class (in django/db/models/
> sql/query.py) accepts a connection argument to its constructor, and
> the QuerySet class (django/db/models/query.py) can be passed an
> optional Query instance - if you don't pass it one, it will create a
> Query that uses the default django.db.connection.

Hmm.. so to the first layer of the onion, that statement is true...
But now, how
does one get a custom connection?  Altnernate connection info  needs
to be
able to be  passed in to the DatabaseWrapper constructors, so that you
can
call them with different database information; and then when
BaseDatabaseWrapper.cursor() calls _cursor() it should pass in a
*copy* of
the global settings overridden with anything passed in as kwargs to
BaseDatabaseWrapper.__init__()
(which is already saved in self.options) .   That is,  instead of
    def cursor(self):
        from django.conf import settings
        cursor = self._cursor(settings)
        if settings.DEBUG:
            return self.make_debug_cursor(cursor)
        return cursor

We should do:

     def cursor(self):
        from django.conf import settings
        mysettings = settings.copy().update(self.options)
        cursor = self._cursor(mysettings)
        if settings.DEBUG:
            return self.make_debug_cursor(cursor)
        return cursor

And then we can do something like
     from django.db.backends.mysql.base import DatabaseWrapper as
OracleDatabaseWrapper
     myconnection =
OracleDatabaseWrapper(DATABASE_HOST='somwhere.example.com',
 
DATABASE_USER='tiger',
                                                                                
  ...
                                                                                
  )
   and then you could use myconnection in your Manager subclass, etc.

Anyhow, that seems to me like it is a stab at addressing the simple
"some
model classes talk to a different database" approach.     One could
make a
ManagerWithAlternateConnection class that is a subclass of Manager and
takes a
database connection as a parameter and does that.
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to