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 select_related and prefetch_related.
One thing to note is that the package is still opt-in in the sense that it requires sealing querysets but we're thinking of adding a setting that enables it by default for all models. Cheers, Simon [0] https://github.com/charettes/django-seal [1] https://docs.python.org/3/library/warnings.html [2] https://docs.python.org/3/library/logging.html#logging.captureWarnings [3] https://docs.python.org/3/library/warnings.html#warnings.filterwarnings Le mardi 28 mai 2019 12:10:26 UTC-4, Flavio Curella a écrit : > > 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 side. But I think > a useful way Django could easily doing more to help debug applications is > to simply add some DEBUG-level logging whenever a related instance gets > fetched. > > The idea would be add logging calls in the `__get__` methods of related > descriptors: > > * > https://github.com/django/django/blob/a44a21a22f20c1a710670676fcca798dd6bb5ac0/django/db/models/fields/related_descriptors.py#L166 > * > https://github.com/django/django/blob/a44a21a22f20c1a710670676fcca798dd6bb5ac0/django/db/models/fields/related_descriptors.py#L395 > > And in the `get_queryset` methods of the related managers: > > * > https://github.com/django/django/blob/a44a21a22f20c1a710670676fcca798dd6bb5ac0/django/db/models/fields/related_descriptors.py#L609 > * > https://github.com/django/django/blob/a44a21a22f20c1a710670676fcca798dd6bb5ac0/django/db/models/fields/related_descriptors.py#L890 > > > Adding some logging seems pretty trivial, but I have a couple of questions > I would appreciate your feedback oon: > > 1. Maybe issuing a warning would be more effective and also prevent those > issues from happening. One additional benefit is that users could turn > those warnings into exceptions, if they wish. > 2. Should this kind of logging also be also applied to fields deferred by > `defer()` and `only()`? > > > [1] Various solutions I've found around: > > * add an argument to the fields / add subclasses of the fields: > https://code.djangoproject.com/ticket/26481, > https://gist.github.com/kyle-eshares/5eaed8a5c299e5282d066a1fbc03152c > * a `sealable` decorator for the model: > https://github.com/charettes/django-seal > > Thank you, > –Flavio. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/97744bb4-143e-4970-be9e-198a3c49b6d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
