Opened 3 years ago

Closed 3 years ago

#18886 closed Cleanup/optimization (invalid)

MySQL backend and _last_executed

Reported by: nagyv Owned by: nobody
Component: Database layer (models, ORM) Version: 1.4
Severity: Normal Keywords: _last_executed mysql last_executed_query
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

this is an extracted version of https://groups.google.com/forum/?fromgroups=#!topic/google-cloud-sql-discuss/55mTyqweXpo

from the django/db/backends/mysql/base.py

# 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.

Using a protected field in the mysql driver seems like the wrong thing for django to do. Is there a substantial difference between the default implementation of last_executed_query() and the one returned by the mysql version?

http://code.djangoproject.com/svn/django/trunk/django/db/backends/__init__.py

def last_executed_query(self, cursor, sql, params):

"""
Returns a string of the query last executed by the given cursor, with
placeholders replaced with actual values.

sql is the raw query containing placeholders, and params is the
sequence of parameters. These are used by default, but this method
exists for database backends to provide a better implementation
according to their own quoting schemes.
"""
from django.utils.encoding import smart_unicode, force_unicode

# Convert params to contain Unicode values.
to_unicode = lambda s: force_unicode(s, strings_only=True, errors='replace')
if isinstance(params, (list, tuple)):

u_params = tuple([to_unicode(val) for val in params])

else:

u_params = dict([(to_unicode(k), to_unicode(v)) for k, v in params.items()])

return smart_unicode(sql) % u_params

Change History (1)

comment:1 Changed 3 years ago by aaugustin

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

Yes, there is a difference, see #14091.

There was a constant flow of tickets because of this difference until we fixed the problem.

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