django-silk VS Norm

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

you're using DRF, which DDT doesn't work well with. DDT is more for template rendered pages, not API responses. Have you brought in Django silk for monitoring this?

https://github.com/jazzband/django-silk/issues?q=is%3Aopen+is%3Aissue+label%3Abug

Are you using Django-silk? Googling for the error shows https://github.com/jazzband/django-silk/issues/374

Those docs are wrong. They still reference syncdb. Use the README at https://github.com/jazzband/django-silk.

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

If you're using Django as an API, without templates, django debug toolbar is useless because it requires templates. It won't work with DRF endpoints which means you miss out on profiling and SQL tracing. That's where django-silk shines.

You can also install django-silk to profile your app, and play around with different implementations.

https://github.com/ansible-community/ara/pull/358 https://github.com/b12io/orchestra/pull/830 https://github.com/batiste/django-page-cms/pull/210 https://github.com/carpentries/amy/pull/2130 https://github.com/celery/django-celery/pull/612 https://github.com/django-cms/django-cms/pull/7241 https://github.com/django-oscar/django-oscar/pull/3867 https://github.com/esrg-knights/Squire/pull/253https://github.com/Frojd/django-react-templatetags/pull/64 https://github.com/groveco/django-sql-explorer/pull/474 https://github.com/jazzband/django-silk/pull/550 https://github.com/keras-team/keras/pull/16073 https://github.com/ministryofjustice/cla_backend/pull/773 https://github.com/nitely/Spirit/pull/306 https://github.com/python/pythondotorg/pull/1987 https://github.com/rapidpro/rapidpro/pull/1610 https://github.com/ray-project/ray/pull/22396 https://github.com/saltstack/salt/pull/61647 https://github.com/Swiss-Polar-Institute/project-application/pull/483 https://github.com/UEWBot/dipvis/pull/216

This is just not liking SQL, which is fine, but it's not 'the future of querying databases'. It's just a simplified language that is under-specified and doesn't really support even a fraction of the use cases of SQL, and therefore looks 'cleaner'. It's a bad abstraction.

Here is my attempt at a 'post orm' if anyone is interested, as a bonus it is fully implemented and some people actually use it: https://github.com/justinvanwinkle/Norm

I tried to do something similar with https://github.com/justinvanwinkle/Norm about 10 years ago. It hasn't generated a lot of interest, but I find it quite useful to construct queries without having to learn the minutia of an ORM library, or even a SQL generation library.