What would be the difference with the new raw method on manager (http://docs.djangoproject.com/en/dev/topics/db/sql/#django.db.models.Manager.raw)?
-- Gert Mobile: +32 498725202 Web: http://gert.selentic.net On Fri, Mar 19, 2010 at 13:39, Sh4wn <[email protected]> wrote: > ## The Django ORM > > ### The Problem > > Django is a awesome webframework, and works quite well. But after > using it for about a year now, I've came across some annoyances. One > great thing of django is the amount of third party reusable apps, > unfortunately, this comes at a cost in the number of database queries. > For example, the comments application, which has a template tag > 'get_comment_count', this tag executes a query everytime when it gets > called. Or even better, the django-avatar app which executes 2 SQL > queries each time the {% avatar %} is called. This is not really > efficient as it often possible to select the required data with > joins. > > With a custom Manager class, you can quite easily annotate the count > of an related object, but unfortunately not for generic relations. > When you want to add the comment count to, for example, a list of news > items, without executing a query for each news item, you'll have to > fallback to the 'extra' method of a queryset, which often will contain > raw SQL. > > ### The Solution > > I want to refactor the QuerySet and other databases related API's, > which adds an additional method of selecting records, and provides > more control of what data you'll select, but probably is a bit more > complex than the current API. It's a bit inspired by Doctrine, a PHP > ORM, and yes, one of the few decent PHP projects. > > Example 1.1: > qs = QuerySet().select(News.all, User.username, > Count('c__id'), comment_average=Avg(OtherModel.field) > ).from(News) \ > .leftJoin('comments c') > .filter(news__title="value") \ > .order_by('comment_average') > (This is just a not-working dummy example) > > As you can see you can explicitly set the fields and tables you want > to select. Beside that the existing queryset methods will remain to > work. There'll be a slight difference though: instead of the related > name in filter/order_by/other methods you don't use the related name, > but the table name specified in the from method. > > The select method supports selecting fields by string and python > object, the same for the from method. In addition, the select method > also supports the builtin django aggregates. Renaming selected fields > works the same as the aggregate method, just use python's named > parameters. > > It also provides a simple method for joins, simply put the name of the > table you want to join, or the model class, and it will automaticly > generate the ON statement, when the two models are related, but is > overrideable with the second parameter of the leftJoin method. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
