I use a bunch of hacks and monkey patches to make ORM master. So I consider a proper cleanup very valuable. This one for example for more efficient pickling: https://gist.github.com/974735
On 10 окт, 03:28, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > 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.
