Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#9405 closed (wontfix)

[patch] DatabaseOperations should track its own connection

Reported by: Joey Wilhelm Owned by: nobody
Component: Database layer (models, ORM) Version: 1.0
Severity: Keywords: multiple database
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

django-db-operations.diff (5.2 KB ) - added by Joey Wilhelm 16 years ago.

Download all attachments as: .zip

Change History (3)

by Joey Wilhelm, 16 years ago

Attachment: django-db-operations.diff added

comment:1 by Malcolm Tredinnick, 16 years ago

Resolution: wontfix
Status: newclosed

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.

comment:2 by Joey Wilhelm, 16 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top