Opened 8 years ago
Last modified 8 years ago
#29081 closed Cleanup/optimization
select_related and hitting the database — at Initial Version
| Reported by: | Дилян Палаузов | Owned by: | nobody |
|---|---|---|---|
| Component: | Documentation | Version: | 2.0 |
| Severity: | Normal | Keywords: | select_related |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
https://docs.djangoproject.com/en/2.0/ref/models/querysets/#select-related says:
… then a call to Book.objects.select_related('author_ _hometown').get(id=4) will cache the related Person and the related City:
b = Book.objects.select_related('author_ _hometown').get(id=4)
p = b.author # Doesn't hit the database.
c = p.hometown # Doesn't hit the database.
b = Book.objects.get(id=4) # No select_related() in this example.
p = b.author # Hits the database.
c = p.hometown # Hits the database.
This leaves the impression, that the first snipped does not hit the database and the second snippet hits twice the database.
I propose:
- wring after
b = Book.objects.select_related('author_ _hometown').get(id=4)the comment # Hits the database with INNER JOIN. - changing
b = Book.objects.get(id=4) # No select_related() in this example.tob = Book.objects.get(id=4) # No select_related() in this example, hits the database., and - changing
p = b.author # Hits the database.top = b.author # Doesn't hit the database.
Note:
See TracTickets
for help on using tickets.