Code

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9405 closed (wontfix)

[patch] DatabaseOperations should track its own connection

Reported by: Tarken 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: UI/UX:

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 Tarken 6 years ago.

Download all attachments as: .zip

Change History (3)

Changed 6 years ago by Tarken

comment:1 Changed 6 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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 Changed 6 years ago by Tarken

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.