Re: Automatic prefetching in querysets

On Monday 21 August 2017 18:44:35 Tobias McNulty wrote: > On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant wrote: > > This could work something like the way that ForeignKey `on_delete` works > > - you have options that are enumerated as constants, but in reality they > > are

Fellow Report - August 19, 2017

I was mostly on vacation this week. Triaged --- https://code.djangoproject.com/ticket/28491 - "TypeError: context must be a dict rather than Context" when using loader.select_template() with Context (invalid) Reviewed/committed --

Re: Optimizing out unused annotations from count queries

On Monday, August 21, 2017 at 11:28:35 AM UTC+3, Tom Forbes wrote: > > > Interestingly enough, just doing a .filter(m2m_relation__foo='bar') > might change the results > > Is that not because it's a filter? Would ". > annotate(x=F('m2m_relation__foo'))" change the results in any way? Sorry if >

Re: Optimizing out unused annotations from count queries

I'm not sure how much QuerySet optimization django should really be doing. Databases' optimizers are really good and as we've seen there are a huge number of edge cases in trying to do the work in Djangoland, as QuerySets don't really correspond to the underlying data model. Here's an example in

Re: Optimizing out unused annotations from count queries

> Interestingly enough, just doing a .filter(m2m_relation__foo='bar') might change the results Is that not because it's a filter? Would ". annotate(x=F('m2m_relation__foo'))" change the results in any way? Sorry if I'm not following. On 21 Aug 2017 06:58, "Anssi Kääriäinen"

Re: Automatic prefetching in querysets

On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant wrote: > This could work something like the way that ForeignKey `on_delete` works - > you have options that are enumerated as constants, but in reality they are > classes that embody the strategy to be used. We could have