Hello Flavio,
We've implemented a solution[0] similar to what you are suggesting that
produces warnings[1]
that can either be turned into logs[2] or elevated to exceptions[3]. We
chose to elevate the warnings
to exceptions during our test suite to make sure covered code enforces the
usage of
My library https://github.com/adamchainz/django-perf-rec also has some
popularity, it's like assertNumQueries on steroids
I'd still like to revisit and one day merge auto prefetch_related that
would turn every N+1 queries into 2 bigger queries (
On Tuesday, May 28, 2019 at 11:48:11 AM UTC-5, James Bennett wrote:
>
>
> I guess my question is: if your devs won't check this in tests, why do you
> expect they'll check it through another mechanism? :)
>
I don't expect them to. The logging is for me, the consultant hired to find
why their
On Tue, May 28, 2019 at 9:30 AM Flavio Curella
wrote:
> But there are many situations where a N+1 can get created and people
> usually have don't write tests for (even if they should have). For example,
> assume this model:
>
I guess my question is: if your devs won't check this in tests, why
`assertNumQueries` is useful in *preventing* accidental N+1 in your views,
and I sure which people would use a lot more.
But there are many situations where a N+1 can get created and people
usually have don't write tests for (even if they should have). For example,
assume this model:
```
#
Have you looked at the assertNumQueries assertion?
https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries
This can let you assert the expected queries and break your tests if
someone accidentally introduces an N+1.
--
You received this
Hi y'all,
One of the most common performance issues we found with our clients is the
"n+1 queries" problem: some code will access some related objects of an
instance that's been fetched without `select_related` or `prefetch_related`.
There are many way this can be improved[1] from the user
