2010-01-25 14 views
8

Ho un'applicazione Python/Django che esegue un numero elevato di istruzioni SQL. Per motivi di debug, ho pensato di creare per me una vista semplice che elenchi tutte le istruzioni SQL che sono state eseguite.Utilizzo di django.db.connection.queries

Secondo la documentazione, questo codice dovrebbe essere sufficiente per farlo:

from django.db import connection 
    connection.queries 

finché DEBUG è True.

Tuttavia, questo non mi sta dando nulla. DEBUG è sicuramente impostato su True. In quale contesto è memorizzata questa connessione? Voglio dire, dovrei essere in grado di eseguire una pagina che esegue molte istruzioni SQL, quindi passare alla vista http://myserver/sql che ho creato e vedere quelle istruzioni SQL lì, giusto? Usando ovviamente la stessa sessione del browser ...

Ho verificato se db.reset_queries() è stato eseguito in qualsiasi parte del codice, sembra che non lo sia.

Qualche idea sul perché connection.queries è sempre vuota?

risposta

17

Ben ha ragione che si vedono solo le query del processo corrente. Puoi usarlo nella stessa vista, o nella console, ma non tra le viste.

Il modo migliore per vedere quali query sono in esecuzione nelle visualizzazioni è utilizzare lo Django debug toolbar.

+0

Controllerò la barra degli strumenti di debug di django. Grazie. – HaukurHaf

+0

Non ho mai avuto successo con DDT su un server di produzione. Sembra funzionare solo con il server di sviluppo di Django in esecuzione localmente. – William

3

Penso che queste query siano archiviate in memoria e non condivise tra processi, in modo da avere accesso solo alle query eseguite dal processo corrente.

Se provo il codice incollato in una sessione ./manage.py shell, vedo solo le query che ho precedentemente effettuato in quella sessione di shell.

Se passo queries da una vista in un contesto modello e lo mostro nel modello, vedo solo le query effettuate in quella vista. Questo sta usando il server di sviluppo, comunque.

Presumo — ma non ho provato — che se si utilizza questo in un ambiente in cui si dispone di un processo che serve più richieste, si vedrebbe più richieste di essere salvate ogni richiesta.

+0

Ok, quindi questo funzionerà solo all'interno di ogni richiesta. Ciò ha senso. Grazie per avermelo fatto notare :-) – HaukurHaf

7

@ Daniel Roseman è una buona idea, ma se volete sapere query SQL, fuori dalla scatola:

installare django-command-extensions e aggiungerlo alle applicazioni installate. si aggiungerà molti comandi utils nel progetto, uno di loro:

  • debugsqlshell: Uscite della SQL che viene eseguito come si lavora nella shell interattiva di Python.

esempio: python manage.py debugsqlshell

In [1]:from django.contrib.auth.models import User 
In [1]:User.objects.all() 

Out[2]: SELECT "auth_user"."id", 
    "auth_user"."username", 
    "auth_user"."first_name", 
    "auth_user"."last_name", 
    "auth_user"."email", 
    "auth_user"."password", 
    "auth_user"."is_staff", 
    "auth_user"."is_active", 
    "auth_user"."is_superuser", 
    "auth_user"."last_login", 
    "auth_user"."date_joined" 
    FROM "auth_user" LIMIT 21 [1.25ms] 
2
from django.db import connections 
x = connections['rating'] 
x.queries 

So check another connections! 
0

Questo è ciò che ha risolto il tutto per me; Io ho usato:

reduce(lambda n, name: n + connections[name].queries, connections, 0) 

per ottenere il conteggio delle query.