views:

193

answers:

1

I'm using the Django ORM in a non-Django application and would like to turn on the DEBUG setting so that I can periodically log my queries. So I have something vaguely like this:

from django.db import connection

def thread_main_loop():
    while keep_going:
        connection.queries[:] = []
        do_something()
        some_logging_function(connection.queries)

I would like to do this on my production server, but the doc warns, "It is also important to remember that when running with DEBUG turned on, Django will remember every SQL query it executes. This is useful when you are debugging, but on a production server, it will rapidly consume memory."

Because the connection.queries list is cleared every time through the main loop of each thread, I believe that Django query logging will not cause my application to consume memory. Is this correct? And are there any other reasons not to turn DEBUG on in a production environment if I'm only using the Django ORM?

+2  A: 

In DEBUG mode any error in your application will lead to the detailed Django stacktrace. This is very undesirable in a production environment as it will probably leak sensitive information that attackers can use against your site. Even if your application seems pretty stable, I wouldn't risk it.

I would rather employ a middleware that somehow logs queries to a file. Or take statistics of the database directly, e.g (for MySQL).

watch -n 1 mysqladmin --user=<user> --password=<password> processlist

Edit:

If you are only using the Django ORM, then afaik only two things will be different:

  • Queries will be saved with the CursorDebugWrapper
  • If a query results in a database warning, this will raise an exception.
stefanw
Well as I said, we're only using the ORM, so our server won't be exposing our stack traces to untrusted third parties even with DEBUG turned on. Are there any other reasons you're aware of to not use DEBUG?
Eli Courtwright
Oh right, I extended my answer.
stefanw