+1 to just add the queryset method it gives a fine granular level of control. Moreover when not used we could display warnings which can help people detect these O(n) query cases as Tom Forbes initially suggested.
On Friday, August 18, 2017 at 9:08:11 AM UTC+3, Anssi Kääriäinen wrote: > > On Thursday, August 17, 2017 at 11:30:45 PM UTC+3, Aymeric Augustin wrote: >> >> Hello, >> >> > On 17 Aug 2017, at 14:48, Luke Plant <l.pla...@cantab.net> wrote: >> > >> > On 16/08/17 23:17, Aymeric Augustin wrote: >> >> It should kick in only when no select_related or prefetch_related is >> in effect, to avoid interfering with pre-existing optimizations. It's still >> easy to construct an example where it would degrade performance but I don't >> think such situations will be common in practice. >> > >> > I think Ansii's example is a non-contrived and potentially very common >> one where we will make things worse if this is default behaviour, >> especially for the non-expert programmer this behaviour is supposed to >> help: >> > >> > >> > if qs: >> > qs[0].do_something() >> > >> > (where do_something() access relations, or multiple relations). We will >> end up with *multiple* large unnecessary queries instead of just one. The >> difference is that the first one is easy to explain, the remainder are much >> harder, and will contribute even more to the "Django is slow/ORMs are bad" >> feeling. >> >> >> I wasn't convinced by this example because it's already sub-optimal >> currently. `if qs` will fetch the whole queryset just to check if it has at >> least one element. >> >> Assuming there's 1000 elements in qs, if you don't care about a 1000x >> inefficiency, I don't expect you to care much about two or three 1000x >> inefficiencies... >> > > I agree that this example isn't particularly worrying. It's something an > experienced developer wouldn't do. On the other hand, we are aiming at > making things simpler for non-experienced developers. > > To me the worrying part here is that we really don't have any data or > experience about if the cure will be worse than the disease. Likely not, > but what do we gain by taking risks here? > > Maybe we should just add the queryset method. This is the smallest atomic > task that can be done. Even if there's only the queryset method available, > it's possible to enable prefetches per model by using a Manager. > > - Anssi > > > -- 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/d956a26d-adcf-443f-80c8-7b7ba290d2b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
