First, if you have time for it, please take a look of #17025 (sql/ WhereNode refactoring). In summary: test suite is 10% faster, creating a simple objects.filter(pk=1) query is 30% faster, chained .filter() calls can be multiple times faster and so on. The code is IMHO cleaner. And it is much better documented. The patch is WIP, but please try it on real world queries (especially if you have problems with queryset cloning) and see if it makes any speed difference. And of course if you can break it.
Now, for the topic of the post. I have worked quite intensively (some might say too intensively) around different issues in the ORM for the last couple of weeks, and my take is that while the code in general makes mostly sense and it is clear that it had a good design to start with, it has slowly bitrotted into a situation where it is nearly impossible to understand it. Case in point, take a look of add_q pre and post #17025 patch. Can you tell from the pre-version what is done and why? I would like to work on refactoring the ORM. This would be slow work, one piece at a time, not a total rewrite. I think there is much potential in the ORM. It needs to be cleaned first, and then we can get hacking new and awesome features. I know there are other people interested in this, too. For example I have been thinking for some time about something like F() objects, but which could contain arbitrary SQL and references to fields in the query. relabel_aliases and cloning would be handled for you. These could be used in .order_by(), values_list, annotate() and so on. SQLSnippet could be its name. This would allow us to deprecate .extra, and would allow for some really fancy extensions. Using these you could implement an external SQL snippets library, the PostgreSQL window functions in one library for example. Or custom aggregate ModelAggregate (fetch related models using array_agg, something like prefetch_related, but runs in single SQL query). I really do believe this is possible. But we need to get the work started on refactoring the ORM first. I do currently have some extra time, and I am willing to work on the ORM. But we need some people reviewing the patches and most of all we need core developers who have enough time to review and commit the ready patches. Unfortunately the ORM-knowing core developers seem to be really busy. I really do not know how to move forward. I guess I am asking all you what do you think should be done with the ORM. We could take a completely opposite direction and make it a wrapper around SQLAlchemy (I saw this mentioned somewhere some time ago). Or decide that the ORM is just fine now, or that there are higher importance items. Before continuing my hacking, it would be nice to know if there is support for ORM refactoring. Thank you for your time, - Anssi Kääriäinen -- 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.
