Changes between Initial Version and Version 1 of Ticket #17003
- Timestamp:
- Oct 6, 2011, 9:44:20 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #17003
- Property Triage Stage Unreviewed → Accepted
-
Ticket #17003 – Description
initial v1 3 3 Often, select_related will be a better alternative for these relationships, since they can be done with a database join. However: 4 4 5 1. It is possible that in practice that doing a separate query and joining in Python is faster.5 1. It is possible that in practice it is better to do a separate query and join in Python. 6 6 2. There are cases where it may be difficult to arrange for the relationships to be included via `select_related()`. For example if you do `prefetch_related('many1__single__many2')`, then, although prefetch_related will ''traverse'' the 'single' relationship to get to 'many2', it could execute many DB queries when it does so. 7 7 … … 10 10 The primary difference for singly related objects is that we have to avoid simply fetching the attribute from the instance, as this will cause the descriptor `__get__()` to be called, and the query to be done immediately the inefficient way. We can do this by calling `getattr` on the class, which will retrieve the descriptor object itself. 11 11 12 For reference, it appears that Ruby on Rails us ingsomething like `prefetch_related()` for all [http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html eager loading of relationships], and doesn't have an equivalent to `select_related()`.12 For reference, it appears that Ruby on Rails uses something like `prefetch_related()` for all [http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html eager loading of relationships], and doesn't have an equivalent to `select_related()`.