[patch] DatabaseOperations should track its own connection

[Joey Wilhelm]

Other database objects (Introspection, Creation) hold their own connection as self.connection, I'm guessing as part of the multi-db work. I have patched DatabaseOperations to do the same, and updated all of the backends to work with this change as well.

The patch shows revision 2, as I've begun maintaining my own local django repo due to some multi-db wonkiness such as this change. My repo is based against the releases/1.0.X/ branch, r9236.

[Malcolm Tredinnick]

I don't think this is a necessary change at the moment. It's not immediately clear that it's the right approach for multiple database support. The DatabaseOperations class only exists inside a DatabaseWrapper class, so there's no confusion about whether it's the right type or not. It shouldn't be doing anything that requires access to an active connection.

Introspection and creation are quite different, one-off operations that need to actually talk to the database. They are more comparable to DatabaseWrapper than DatabaseOperations.

[Joey Wilhelm]

An advance warning: I apologize if this sounds a bit snippy, it's not meant to; mild hangover and coffee hasn't kicked in yet. :)

I honestly have to disagree, and you assertion that "It shouldn't be doing anything that requires access to an active connection." is proven false by what is changed in this patch. The Oracle backend, in regex_lookup(), grabs a cursor. The PostgreSQL backend does as well in _get_postgres_version(). django-pyodbc also references properties of the connection in both sql_flush() and field_cast_sql().

True, this is not a "necessary" change at the moment, but it works, does not change the API as far as users are concerned, and provides an extra bit of caution. In the case of what I am currently doing with Django (as mentioned in my comment on #1142 and on the django-developers mailing list), this is an absolutely necessary patch. Without it, I end up calling the psycopg2 operations for an MS SQL connection.

One piece of your comment I'm not 100% clear on though is the statement, "It's not immediately clear that it's the right approach for multiple database support." Regardless of what direction the multiple database support takes, would it not be cleanest to have these things keep tabs on their own information? If, for example, the 'using' proposal ends up being implemented, the methods mentioned above which do reference an active connection will either need to figure out what connection is being used and reference that one, or do exactly what's being offered up here.