Don't be so sure.
The gsoc2009 multi-db branch that Alex was working on over the summer
is usable, as long as you don't mind a couple of sharp edges. There's
only a small handful of issues left, and most of those are really
about the internals. What is in the branch is reasonably well
documented - the two changes to look for are the new DATABASES
setting, and the using() method on querysets.
There is still some work to be done to make the public interface a
little easier to use for some common use cases; the more feedback we
get on these aspects, the better.
So - if you're feeling adventurous (and if you're willing to try out
multidb on your own, I'm guessing you are), it's worth taking a look
at Alex's branch.
Yours,
Russ Magee %-)
> My problem occurs during larger queries - I get 'Too many connections'
> error. If I run these queries through django's default manager they
> are handled fine. Can anyone point me in the right direction, maybe
> the source code where django handles this. I'm pretty sure I need to
> close the connection in my MultiDBManager but not sure how to
> accomplish this.
>
If you mean something based on MultiDBManager here:
http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
I think it makes an awful lot of DatabaseWrappers as-is. I _think_ (but
could be wrong), that seriously lowers connection reuse, so you end up
with a lot of dangling connections.
Here's something further pared down I'm currently testing with django
1.1.1 to tide us over until true multi-db for our own simple
multi-postgresql-database case. It "seems to work", though doesn't
address a bunch of stuff true multi-db would cover - I just needed
(okay, wanted) read-only access to an extra database through django orm,
but you could probably add Eric's _insert. I also only use processes not
threads, with mod_wsgi daemon mode. Doing it this way, you should
probably consider an altconnection1.close() sometimes (it won't happen
implicitly sometimes unlike the main connection), but it's only using
one extra DatabaseWrapper instance per extra database.
from django.conf import settings
from django.db import backend
altconnection1 = backend.DatabaseWrapper(
'DATABASE_HOST': settings.DATABASE_HOST,
'DATABASE_NAME': "altdb1",
'DATABASE_OPTIONS': settings.DATABASE_OPTIONS,
'DATABASE_PASSWORD': '',
'DATABASE_PORT': '',
'DATABASE_USER': settings.DATABASE_USER,
'TIME_ZONE': settings.TIME_ZONE,
})
class ExtDBManager(models.Manager):
def __init__(self, connection, *args, **kwargs):
self.connection = connection
super(ExtDBManager, self).__init__(*args, **kwargs)
def get_query_set(self):
qs = super(ExtDBManager, self).get_query_set()
qs.query.connection = self.connection
return qs
class MyModel1(models.Model):
class Meta:
managed = False
db_table = 'table1'
objects = ExtDBManager(altconnection1)
...
class MyModel2(models.Model):
class Meta:
managed = False
db_table = 'table2'
objects = ExtDBManager(altconnection1)
...
> Here's something further pared down I'm currently testing with django
> 1.1.1 to tide us over until true multi-db for our own simple
> multi-postgresql-database case. It "seems to work", though doesn't
> address a bunch of stuff true multi-db would cover
> class ExtDBManager(models.Manager):
...
Hmph. In case some poor soul stumbles on this thread in the archives-
Turns out that didn't quite work as it was for many to many fields, as
they try to construct a further subclass of the manager. So, a factory
function that churns out instances of subclasses with the extra
connection as a class field so that the further subclassing inherits the
connection - i.e.
def make_extdbmanager(conn, *args, **kwargs):
if isinstance(conn, basestring):
c = get_connection(conn) # just a convenience function
else:
c = conn
class _ExtDBManager(models.Manager):
connection = c
def get_query_set(self):
qs = super(_ExtDBManager, self).get_query_set()
qs.query.connection = self.connection
return qs
return _ExtDBManager(*args, **kwargs)
Yeah, this is probably all not the best idea ever, but all just to tide
us over.