Doesn't work with new django multi-database framework

[GoogleCodeExporter]

(Django multi-database framework: 
http://docs.djangoproject.com/en/dev/topics/db/multi-db/)

Currently the _get_sql_server_ver() function in DatabaseOperations uses 
django.db.connection to query the SQL Server version.  django.db.connection 
uses the default database, so this doesn't work if we're querying from a 
non-default database.

I think the fix for this is fairly easy.. I've been able to hack bits of it 
to work by passing in the 'connection' parameter to this function.

Eg. "self.connection.ops.sql_server_ver < 2005" becomes 
"self.connection.ops._get_sql_server_ver(self.connection) < 2005".

Original issue reported on code.google.com by ama...@gmail.com on 2 Feb 2010 at 12:20

[GoogleCodeExporter]

I attempted to patch it using your suggestion, but my QuerySets are always 
returning
an empty list even though the database is populated. This occurs with or 
without the
QuerySet.objects.using clause. The same QuerySets pointing to the same database 
work
well when just using a single database. There must be something else going on.

Original comment by djfis...@gmail.com on 5 Feb 2010 at 9:16

Attachments:

• django-pyodbc-multidb.diff

[GoogleCodeExporter]

I had mistyped _sql_server_version instead of _get_sql_server_version. The 
following
patch for me is working against the Django trunk (12398) and two MSSql2008 
databases
from Linux using FreeTDS.

Original comment by djfis...@gmail.com on 9 Feb 2010 at 12:41

Attachments:

• django-pyodbc-multidb.diff

[GoogleCodeExporter]

I should note that my "default" database was a MySQL database that I connected 
to
with 'django.db.backends.mysql'. I did not try to syncdb to the MSSql databases.

Original comment by djfis...@gmail.com on 9 Feb 2010 at 12:48

[GoogleCodeExporter]

There are other places where the _get_sql_server_version() call causes
problems--especially when accessed via the sql_server_ver property since those 
cases
cannot pass "connection".  DatabaseOperations.field_cast_sql() is one such case.

Original comment by jrjar...@gmail.com on 2 Mar 2010 at 11:02

[GoogleCodeExporter]

You're right. My patch doesn't solve the whole problem. Perhaps the best way to 
solve
this is to specify the version in DATABASE_OPTIONS. I'm not sure that a backend
should be querying to find out the version on the fly anyway.

Original comment by djfis...@gmail.com on 3 Mar 2010 at 5:45

[GoogleCodeExporter]

Actually, I think a better solution is to do what the Postgres backend does. The
DatabaseOperations object in the Postgres backend also needs to know the 
database
version in order to perform some database specific functions (sql_flush for 
example).

The Postgres solution is to pass the connection object to the DatabaseOperations
constructor. This would solve the problem we have in operations.py where we 
have to
import the connection and we are getting the default connection. We should 
never need
to import the connection because it is part of the object.

Original comment by djfis...@gmail.com on 3 Mar 2010 at 7:05

[GoogleCodeExporter]

Here's my updated patch to pass the connection object along as I suggested in 
comment
#6. It passed my preliminary tests, but I haven't tested it widely yet.

Original comment by djfis...@gmail.com on 3 Mar 2010 at 7:35

Attachments:

• django-pyodbc-73.diff

[GoogleCodeExporter]

I'm successfully using this for a read only model in a production app, along 
with the 
patch submitted for issue #76 with no problems. Thanks! I hope this makes it 
into the 
trunk soon!

Original comment by reconbot on 18 Mar 2010 at 1:42

[GoogleCodeExporter]

I came to the same conclusion and applied basically the same patch. Been 
working 
nicely for me :)

Original comment by julian.d...@gmail.com on 22 Mar 2010 at 11:24

[GoogleCodeExporter]

It's working for me! Thank you!

Original comment by xiehaife...@gmail.com on 26 Apr 2010 at 2:48

[GoogleCodeExporter]

Fixed in revision 180, thanks.

Original comment by vcc.ch...@gmail.com on 30 Apr 2010 at 5:08

[GoogleCodeExporter]

Original comment by vcc.ch...@gmail.com on 30 Apr 2010 at 5:08

• Changed state: Fixed