Django-CRM VS django-query-profiler

Micropyramid team welcomes developers to contribute their code to our opensource project Django CRM. Only the developers have that weapon to build a fantastic experience that people might love. If interested in our opensource Django project, visit us @ https://github.com/MicroPyramid/Django-CRM

Contribute your code for our opensource project Visit us @ https://github.com/MicroPyramid/Django-CRM

Visit us @ https://github.com/MicroPyramid/Django-CRM We would be glad if you contribute your code to our project.

Contribute to our opensource django project @ https://github.com/MicroPyramid/Django-CRM

We would be happy if you contribute your code to our open-source Django project and help us make an improved robust software. Visit Us @ https://github.com/MicroPyramid/Django-CRM/

Our project Django CRM is an open-source CRM developed in the Django framework. We welcome code contributions and feature requests via GitHub. We would be immensely happy if you give your precious time to our Django project. Visit us @ https://github.com/MicroPyramid/Django-CRM

But that's still not backend-specific SQL?

There should be an interface method for this. Why does psycopg call it mogrify?

https://django-debug-toolbar.readthedocs.io/en/latest/panels... :

> debug_toolbar.panels.sql.SQLPanel: SQL queries including time to execute and links to EXPLAIN each query

But debug toolbars mostly don't work with APIs.

https://github.com/django-query-profiler/django-query-profil... :

> Django query profiler - one profiler to rule them all. Shows queries, detects N+1 and gives recommendations on how to resolve them

https://github.com/jazzband/django-silk :

> Silk is a live profiling and inspection tool for the Django framework. Silk intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection

I agree that this stuff can definitely be handled better.

https://github.com/django-query-profiler/django-query-profil... has a neat option for detecting likely N+1 queries. I usually use the Django Debug Toolbar for this.

Django's ".only()" method lets you specify just the columns you want to retrieve - with the downside that any additional property access can trigger another SQL query. I thought I'd seen code somewhere that can turn those into errors but I'm failing to dig it up again now.

I've used the assertNumQueries() assertion in tests to guard against future changes that accidentally increase the number of queries being made without me intending that.

The points you raise are valid, but there are various levels of mitigations for them. Always room for improvement though!

If you are trying to optimize for N+1 queries, django query profiler is another cool profiler. It is very simple to configure (requires changing 3-4 lines in your settings.py file), and works the same way with a chrome plugin and the command line.