Hello, > On 5 déc. 2015, at 10:28, Raphael Gaschignard <raph...@rtpg.co> wrote: > > A behaviour that exemplifies this is that > queryset.annotate(foo=thing).annotate(bar=other_thing) is not the same as > queryset.annotate(foo=thing, bar=other_thing) given certain things. This goes > against the intuitive interpretation of the queryset API IMO.
Isn't this the same difference as between queryset.filter(foo__bar=bar).filter(foo__baz=baz) and queryset.filter(foo__bar=bar, foo__baz=baz)? I’m asking because if the answer is “yes”, then we want to keep the two APIs consistent and we can’t quite change how chained filter calls set up joins. I don’t quite have a good answer about your other questions… I know that some people will say “stick to raw SQL”. That’s even what the documentation advises. However it appears that the ORM’s ability to compose querysets is so powerful that it outweighs the greater expressivity of SQL in many practical cases. When writing complex aggregations, I’ve had more luck trying to express the logic with Django’s APIs than trying to produce a particular SQL query. It was still very frustrating and mostly based on trial and error. -- Aymeric. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9420983C-F884-4720-952C-76C70B9FB469%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
