On Wed, 2014-12-17 at 03:12 +0200, Shai Berger wrote: > <SNIP> > But deeper checking[4] finds that the > annotation does not do the intuitive thing -- at least when aggregating over > the related objects themselves (rather than fields on them), the field it > uses > to aggregate on is the relation field (object_id, by default) rather than the > pk. This is very odd behavior, as the relation field is guaranteed to be > equal > on all child records of a given record -- and equal to the pk of the parent > record; thus, the only meaningful aggregation is Count().
I investigated this a bit, and the problem is deeper in generic relations handling. Even filtering on generic relations use the related field's value, not the related model's primary key value. We should fix that, too. Luckily the impact of the annotation case isn't that big. Even if the target would have been the related model's primary key there aren't that many sensible queries to run against the PK. The impact of changing the way .filter() works might be a bit bigger, but I think we will need to do this as a bug fix. Case where queries "worked" as in they produced results but the results were incorrect are nasty to fix. Somebody is always relying on the incorrect results. What was fixed (in 1.6 if I recall correctly) was aggregation over generic relations when the target field isn't the generic relation itself, but some other field on the related model. - 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1418800867.6766.29.camel%40TTY32. For more options, visit https://groups.google.com/d/optout.
