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 (
Hi all.
Calendar Week 19 -- ending 12 May.
Triaged:
https://code.djangoproject.com/ticket/30472 -- Argon2id should be supported
and become the default variety for Argon2PasswordHasher (Accepted)
https://code.djangoproject.com/ticket/30469 -- Boolean False becomes NULL
with recent
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
As Adam states before, in the first reply to your original message, this
mailing list is for the internal development of Django and not for getting help
with your Django projects.
There are numerous other places to ask, check his email for a few, and a lot of
people (myself included) willing
Thanks for your answer, but this isn't working. Could you help me with
another solution
On Monday, May 27, 2019 at 10:06:37 PM UTC+5:30, rajan khadka wrote:
>
> in this
>
> from django.urls import URLPattern, url
> from . import views
>
> urlpatterns = [
> url('', views.index, name=index),
>
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
10 matches
Mail list logo
