4 ms·
I recently upgraded to 1.1 because we needed the new aggregation/annotation features. For instance, this is a query we were doing before: articles = Articl
by thomaspaine 17y ago
I recently upgraded to 1.1 because we needed the new aggregation/annotation features. For instance, this is a query we were doing before:
articles = Article.objects.filter(share__sharedOn__range=date_range).distinct()
articles = sorted(articles,key=lambda k: k.TotalRecipients(date_range),reverse=True)
which was achingly slow because it involved making a couple thousand SQL queries during the sorting phase. With annotation we can just do:
articles = Article.objects.filter(share__sharedOn__range=date_range)\
.annotate(total_recipients=Count('shares__recipients')).order_by('total_recipients')
which is much much faster and more efficient. Without annotation, we would have had to manually write the SQL or denormalize a bunch of ManyToMany fields, neither of which I was too excited about.
- ubernostrum 17y agoI have a suspicion that you might have been able to do it more efficiently (e.g., in one query) using extra() to provide a similar effect to the annotation. That's how I typically handled this sort of thing prior to aggregates landing.
- old-gregg 17y agoI don't know how you Python guys, with your drive for readability and elegance which I admire, can tolerate so many underscores in your OOP code. This looks like C preprocessor to me.
- igorgue 17y agoIt makes sense a lot, since you can't have comparison in the parameters (you'll pass a boolean instead of the comparison). I totally understand you, but, I think its the best way to go, of course this is one example, and its very complicated, most of the time you'll only need one of those parameters.