+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 Thu
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 something
similar - `on_missing_relation=FETCH | WARN | ERROR | IGNORE ... `
Luke
On
Hello,
I think there is potential room for improvement with how Django handles
count() queries, specifically relating to annotations. Currently any
annotations that are added to a queryset are included in the SQL statement
that is generated in the count() query, including all joins and SQL
function
I'd like to see this provided all bases were covered. I'll just list below
the cases where I think it wouldn't be safe.
- Filtered annotations
- Annotations that join to anything other than a non-null foreign key:
.annotate(local=F('related__field'))
- Annotations that have a GROUP BY on fields
Thanks for your reply Josh. Can you elaborate on why optimizing out '
.annotate(local=F('related__field'))' would not be safe?
On 20 Aug 2017 00:10, "Josh Smeaton" wrote:
I'd like to see this provided all bases were covered. I'll just list below
the cases where I think it wouldn't be safe.
- Fi
Thanks for making me elaborate, because I'm probably wrong. I'll step
through what my thinking was though.
'.annotate(local=F('related__field'))' will join to the related table. If
`related` is a nullable foreign key, then a join would do an implicit
filter, removing the row from the result set
