[jlafon]

For those interested, here are a couple of differences between this and django-debug-toolbar (an excellent, widely used utility that also provides SQL inspection).

1. django-debug-toolbar can be difficult to enable if you aren't serving from localhost (for security reasons, because your settings are included in the UI). This project looks much simpler to enable, as you just set DEBUG=True in your settings.

2. django-debug-toolbar provides its information through a UI component embedded in your own UIs, but it doesn't help you with profiling HTTP APIs that don't have a UI. In contrast, this project puts some profiling information in the response headers, and SQL logs are sent to a logger. I think this use case is where Django Query Inspector shows a lot of utility.

[StavrosK]

I don't understand #1. You can have DjDT show up only on a condition, e.g. when someone is a superuser. Isn't it the same as this project?

[jlafon]

What I meant is that getting the toolbar to show up when you aren't serving from localhost isn't as trivial as setting DEBUG=True. It requires other settings (https://github.com/django-debug-toolbar/django-debug-toolbar...) which can be annoying to configure.

[dalore]

Checking for a user will break caching though.

[nwenzel]

"but it doesn't help you with profiling HTTP APIs that don't have a UI"

That's been my only complaint about an otherwise fantastic debug tool.

Anyone have any thoughts on running multiple debug tools like these together? I think mostly you would get comfortable with one and stick with it.

[jlafon]

I end up using Django Rest Framework (http://www.django-rest-framework.org/) generated UIs along with the debug toolbar, and then disabling the generated UIs when I'm done profiling.

[integricho]

Also, the browsable api that DRF provides can be used to perform the profiling with django-debug-toolbar.