Code

Opened 22 months ago

Closed 9 months ago

Last modified 9 months ago

#18592 closed Cleanup/optimization (fixed)

Provide failure recovery for undocumented "_last_executed" in MySQLdb's cursor

Reported by: reames@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.4
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

A little bit of context: I'm trying to run django 1.4 on Google AppEngine using CloudSQL, vanilla django 1.4 (and pytz) are in my project directory.

So, in theory, I should be able to use django unmodified. Not the case I've found. I was getting a traceback when doing syncdb to "last_executed_query" in the mysql backend.

My workaround, or fix as it may be, is to change around line 238 in db/backends/mysql/base.py
from

    def last_executed_query(self, cursor, sql, params):
        # With MySQLdb, cursor objects have an (undocumented) "_last_executed"
        # attribute where the exact query sent to the database is saved.
        # See MySQLdb/cursors.py in the source distribution.
        return cursor._last_executed

to

    def last_executed_query(self, cursor, sql, params):
        # With MySQLdb, cursor objects have an (undocumented) "_last_executed"
        # attribute where the exact query sent to the database is saved.
        # See MySQLdb/cursors.py in the source distribution.
        return getattr(cursor, '_last_executed', None)

Attachments (1)

18592.diff (2.4 KB) - added by claudep 22 months ago.
Graceful failure for MySQL _last_executed

Download all attachments as: .zip

Change History (8)

Changed 22 months ago by claudep

Graceful failure for MySQL _last_executed

comment:1 Changed 22 months ago by claudep

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Cleanup/optimization

comment:2 Changed 10 months ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 59b0c48ce27951048146358739baf08056c5e821:

Fixed #18592 -- Prevented crash when accessing MySQL _last_executed

Thanks reames at asymmetricventures.com for the report.

comment:3 Changed 10 months ago by Claude Paroz <claude@…>

In 59be2c6875eaf744798d14c9dc8498552c8d48d5:

[1.6.x] Fixed #18592 -- Prevented crash when accessing MySQL _last_executed

Thanks reames at asymmetricventures.com for the report.
Backport of 59b0c48ce from master.

comment:4 Changed 10 months ago by aaugustin

  • Resolution fixed deleted
  • Severity changed from Normal to Release blocker
  • Status changed from closed to new

The test introduced in this commit fails under Oracle -- probably because Oracle suffers from the same problem that was fixed for MySQL:

http://ci.djangoproject.com/job/Django%20Oracle/143/database=oracle,python=python2.7/testReport/junit/backends.tests/LastExecutedQueryTest/test_last_executed_query/

Also, I'm not convinced by this pattern:

try:
    do_stuff()
except Exception:
    self.fail(...)

It does exactly the same thing as:

do_stuff()

but it obfuscates the error by swallowing the stack trace.

Last edited 10 months ago by aaugustin (previous) (diff)

comment:5 Changed 10 months ago by claudep

I'm sorry, but I have no Oracle setup (and don't intend to have one). If someone with Oracle knowledge could step in, would be nice!

About the pattern, I'm always a bit uncomfortable to create a test case without any assertion. And in that case, when the test fails, an error is raised. But it might be totally fine. Do you have a good reference about this? Then, if decided, we should fix all these patterns throughout Django tests.

comment:6 Changed 9 months ago by claudep

  • Resolution set to fixed
  • Status changed from new to closed

comment:7 Changed 9 months ago by claudep

Also backported to 1.6 in ae685e54cb8b5d654180ac66b9fd4d68ad28a66b

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.