Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#5236 closed (wontfix)

Provide stack trace information in sql debug entries

Reported by: calvin@… Owned by: PhiR
Component: Database layer (models, ORM) Version: master
Severity: Keywords: feature debug
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Hi,

when profiling django views I often use the list of stored SQL queries to review. What I am missing there is where each of the SQL statements comes from. So I added a stack frame text to each of them.
I have not measured the performance impact, but since it only affects installations with DEBUG=True, I consider the tradeoff acceptable.

The patch also simplifies the debug entry by splitting off the storing to a separate method save_entry().

Attachments (2)

django_sql_debug_stack.patch (1.6 KB) - added by Bastian Kleineidam <calvin@…> 8 years ago.
5236.diff (3.2 KB) - added by PhiR 8 years ago.
patch slightly cleaned up, but mostly documented in the FAQ

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by Bastian Kleineidam <calvin@…>

comment:1 Changed 8 years ago by Simon G. <dev@…>

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 8 years ago by PhiR

  • Keywords feature debug added

comment:3 Changed 8 years ago by PhiR

  • Owner changed from nobody to PhiR

Changed 8 years ago by PhiR

patch slightly cleaned up, but mostly documented in the FAQ

comment:4 Changed 8 years ago by PhiR

  • Status changed from new to assigned

comment:5 Changed 8 years ago by PhiR

  • Triage Stage changed from Design decision needed to Ready for checkin

comment:6 Changed 8 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from assigned to closed

Thanks for taking the time to make the patch, but no thanks. Running with DEBUG=True is useful in a lot of situations and we don't need this type of overhead all the time there.

If you want to do this, you can replace the CursorDebugWrapper.execute with your own function in, say, settings.py, so no changes to core are necessary (the advantage of functions as first class objects).

comment:7 Changed 5 years ago by CBWhiz

Just in case anybody is still looking for this, create a new app and throw this into the _ _init_ _.py:

from django.conf import settings
DEBUG_SQL_STACK = getattr(settings, 'DEBUG_SQL_STACK', False)
if DEBUG_SQL_STACK:
    from time import time
    import traceback
    import django.db.backends.util
    class TracingCursorDebugWrapper(django.db.backends.util.CursorDebugWrapper):
        def trace_entry (self, sql, start): 
            stop = time()
            entry = { 
                'sql': sql, 
                'time': "%.3f" % (stop - start), 
                'stack': traceback.format_stack()[:-2],
            }
            self.db.queries.append(entry)
            
        def execute(self, sql, params=()):
            start = time()
            try:
                return self.cursor.execute(sql, params)
            finally:
                sql = self.db.ops.last_executed_query(self.cursor, sql, params)
                self.trace_entry(sql, start)
        def executemany(self, sql, param_list):
            start = time()
            try:
                return self.cursor.executemany(sql, param_list)
            finally:
                sql = '%s times: %s' % (len(param_list), sql)
                self.trace_entry(sql, start)
    django.db.backends.util.CursorDebugWrapper = TracingCursorDebugWrapper

then add the app to your INSTALLED_APPS settings, and set DEBUG_SQL_STACK = True in your settings.py file. Works with 1.2.

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