On Jul 2, 5:57 am, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > In step 1 Django constantly keeps the correct join information and > filtering conditions available. These are ready to be converted into > SQL on the spot. In addition, some information is kept available, but > it isn't processed yet. For example: select_related, order_by etc. > These are just lists of what is wanted, but these are not turned into > joins yet. It is notable that the join information can be changed on > the fly: some operation might turn some existing inner joins to outer > joins for example. Here the main part of complexity is in deciding > what kind of joins to use, or if a subquery is needed.
The logic that Django has for querying in this regard would remain intact. > > In step 2 things like needed GROUP BY clauses is calculated. In > particular, the order_by, select_related and only()/defer() structures > are calculated. Here the most complex part is calculating which joins > to use for select_related descent. In addition there are some details > and dependencies which make this somewhat complex (select cols must be > added to group by - but some backends do not allow using select > aliases in group by, and some backends prefer doing group by only by > table pk). While there is a lot of logic in Django's query here that probably needs to remain in some form, the SQLAlchemy ORM does do a lot of this part, if I understand select_related() correctly, via its eager loading via joins and subqueries capabilities. Joined eager loading does do the "convert from JOIN to OUTERJOIN if an ancestor is an OUTERJOIN" thing, as well as "wrap the whole query in a subquery and apply the joins to that if the query has limit/offset applied". Eager loading is where SQLAlchemy does do a lot of these "automatic" things (though probably not nearly as many as Django). A port of the Django ORM to that of SQLAlchemy would certainly want to get at SQLAlchemy's collection loading facilities as SQLA's collections are associated in memory with parent objects and have very different behavior from collections that load each time they are accessed (we call this latter type of collection a "dynamic" collection). However, that all assumes the proposal to use the SQLAlchemy ORM as the core for Django's which even I think is a little ambitious. I do have a notion of how an *alternate* Django ORM compatibility layer could be provided but I think it would require expectation of significant behavioral differences - it would mostly be a way for an existing application build on Django models and QuerySet usage to port to a SQLAlchemy ORM paradigm without too many changes. But I don't know that you could just hoist those paradigm shifts onto everyone at once without a lot of problems, and its certainly not what a lot of people would want. As far as Luke's proposal to use just SQLAlchemy Core, all of #1 and #2 is still handled 100% by django's query system. > Finally, in step 3 the SQL is generated. This is dirty as different > backends have endless amount of little differences in their take of > what is legal SQL. this is of course the area where both Django and SQLAlchemy core have tremendous overlap and I'm confident SQLA's expression language can do whatever is needed here in a straightforward way. > > I don't see SQLA helping much in step 1 - it just doesn't do what > Django does. It might help somewhat in step 2. It would definitely > help in step 3. > > My understanding is that SQLA and Django's ORM work on different > levels. I do support trying to use SQLA. This is just a warning that > one should not expect to replace everything or even most of the code > under django/db/models/sql and django/db/backends by SQLA. totally agree, the usage paradigm of Django's ORM is very different from that of SQLAlchemy's. -- 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.
