dobarkod / django-queryinspect Goto Github PK

I've noted that a few queries aren't caught by this (terrific) plugin. Specifically, some of the Django-specific queries don't seem to show up in the output:

• select ... from django_session
• select ... from auth_user

Other middleware that logs SQL queries seem to catch these queries, so it's definitely possible. I think the issue may be that callproc isn't implemented in the CursorDebugWrapper class, and perhaps those canned queries are stored as procedures.

https://adamj.eu/tech/2020/07/23/how-to-make-always-installed-django-database-instrumentation/

I just read that article, and it immediately made me think of queryinspect. Using Django DB Instrumentation system seems like it would dramatically simplify queryinspect's code.

The current release 0.0.4 causes deprecation warnings when used with Django 1.8.
The required changes seem to be present, the only thing missing is a new release.

Currently the logger name 'qinspect' is hard-coded:

log = logging.getLogger('qinspect')

How would i use queryinspect for django tests ?

Using this with Django 1.9.12 and just observed, that the time reported in the stats continues to grow, with repeated 404 responses (via raise Http404). So after a while i get:

[SQL] 1 queries (0 duplicates), 0 ms SQL time, 175554 ms total request time

After a response with HTTP 200, the timer seems to reset.

Hey,
Django-queryinspect is pretty useful, but currently there is no release that supports 1.10. Can you push an update to PyPi?

Thanks! And thanks for this library 👍

I received this error only in the first request after I started the runserver command.

'JQuery Inspect Middleware' object has no attribute 'request start'

Steps to reproduce:

1. Logout
2. Restart the server `./manage.py runserver
3. In the browser: http://localhost:8000/admin (without the final slash)

This is an awesome project! Congrats! It'a amazing how complete it is.

For me it would be nice to be able to use the queryinspect programatically instead of coupling it to my project and making it depending on settings.

I teach a lot and work on many projects that need refactoring and performance improvements. So I think it would be great to use the inspector without the middleware.

I have some rudimentary solution for what I need with the logdb function fo sqlformatter. You can see the source at here.

Be decoupling the inspector from the predetermined workflow of a middleware one could:

• use as a view decorator
• use as a contextmanager
• turn it on on the beginning of a process and off somewhere else.
• easily integrate with other tools like django-debugtoolbar and django-devserver

If you feel this is aligned with your vision, I can do some work on that.

Again, congrats and thanks for sharing.

On Django 3.1 I get the following error after following the installation guide:

ValueError: dictionary doesn't specify a version

The solution is to add

'version': 1,

to the LOGGING dict.

As I know, middleware class is initialised once and shared by threads, in your class, your are using instance variables to store state, are you sure it is thread safe?

I follow the instructions but it seems like doesn't work.
Could you explain to me?