On 30/06/12 20:23, Anssi Kääriäinen wrote:
> TL;DR ;) But I intend to do so shortly.
>
> For now I have to comment on the "clear up sql/query.py" part. I am
> doubtful if moving to SQLAlchemy will solve the sql/query.py and sql/
> compiler.py complexities.
>
> I have little knowledge of SQLAlchemy, but my understanding is that it
> does not do things like "when filtering on negated multijoin
> condition, push the condition to subquery", automatic grouping by the
> right set of columns or handle what kind of joins are needed by select
> related. It probably doesn't do join promotion ("should this join be
> INNER or LEFT OUTER join, if dealing with an ORed where condition,
> then LEFT OUTER, and so on). The sql/query.py deals mostly with these
> kinds of problems. The sql/compiler.py also deals in part with
> problems like this.
Mike Bayer pointed me to this code, which does something like Django's
join syntax on top of SQLAlchemy:
https://github.com/mitsuhiko/sqlalchemy-django-query/blob/master/sqlalchemy_django_query.py
I really don't know enough to know how well it is approximating what
Django does. It would be surprising if it was really doing the same thing!
I think it's one of those things where we really won't know the impact
until we've got most of the way there, and even then differences of
approach could make all the difference.
Luke
--
Parenthetical remarks (however relevant) are unnecessary
Luke Plant || http://lukeplant.me.uk/
--
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.
