Very nice work Akaariai.
I'll check this out over the next couple of days :)
Cal
On Mon, Jul 4, 2011 at 10:10 PM, akaariai <akaar...@cc.hut.fi> wrote:
> I have implemented proof of concept versions of conditional
> aggregation, F-lookups in aggregates and annotating fields to a model
> (qs.field_annotate(age_x2=F('age')*2), note: no aggregation here). See
> ticket #11305 for more details.
>
> I would also hope to implement a patch which would allow to annotate
> reverse related models. The idea would be most useful for fetching
> translation models.
>
> Given models:
> Article(
> id=IntegerField()
> default_lang=CharField()
> )
> ArticleTranslation(
> article=ForeignKey(Article, related_name='translations')
> name=TextField()
> abstract=TextField()
> content=TextField()
> lang=CharField()
> class Meta:
> unique_together = ('article', 'lang')
> )
>
> And queryset:
> Aricle.objects.annotate(
> translation_def=ModelAnnotation(
> 'translations',
> only=Q(translations__lang=F('default_lang'))
> ),
> translation_fi=ModelAnnotation(
> 'translations',
> only=Q(translations__lang='fi')
> )
> )
>
> The above query would generate something like this:
> select article.id, article.default_lang, t1.name, ..., t3.name
> from article
> left join article_translation t1 on article.id = t1.article_id and
> t1.lang = 'fi'
> left join article_translation t3 on article.id = t3.article_id and
> t3.lang = article.default_lang
>
> And the objects returned would have (possibly None-valued)
> translation_fi and translation_def instances attached to them.
>
> These features require a lot of work before anything commit-quality is
> ready. I would ask if the community would consider these ideas before
> I do too much work. These patches would also require some attention
> from somebody with more ORM knowledge than I have. The ModelAnnotation
> idea is probably too hard for me to implement in even near commit-
> quality.
>
> These features would naturally make the ORM more powerful, but I see
> some objections to these features:
> 1. They will make the already complex ORM even more complex. This
> will result in new bugs and it will be harder to add new features to
> the ORM.
> 2. Django ORM has the philosophy of "80/20". Meaning that the ORM
> should make it possible to run 80% of your queries, the rest can be
> done using raw SQL. Are these features beyond the 80% threshold?
> 3. As the queries become more complex, it is likely that the ORM will
> not be able to generate efficient SQL. If this is the case raw SQL is
> needed. Back to square 1.
> 4. The ORM is nearing the point where the API is too complex. Instead
> of writing complicated SQL, you will be writing complicate ORM
> queries.
>
> On the other hand, combined with custom F() expressions, the need
> for .extra() would be smaller and maybe it could even be deprecated in
> the future.
>
> - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
