On 30 kesä, 17:22, Luke Plant <l.plant...@cantab.net> wrote:
> Hi all,
>
> A good while back I put forward the idea of using SQLAlchemy Core in
> Django [1]. Having had more experience working with SQLAlchemy, I'm
> putting that idea forward as a formal proposal, as I mentioned in a more
> recent thread here.
>
> Apologies in advance for the length! I've included a few 'TL;DR'
> summaries and headings in the different sections which you might want to
> scan first.
<SNIP>
> == Motivation 3: Code cleanup
>
> As mentioned, our own query generation has been pushed to the limit and
> beyond. (I'm talking about classes like Query, SQLCompiler). It has
> grown and grown, so that the Query class is now a 2000 line behemoth,
> containing a constructor with over 40 assignments to 'self'.
>
> Most of the core developers are scared to touch this stuff, AFAICS,
> myself included. It has no virtually no unit tests. While it has very
> high test coverage, it is tested only by tests that check QuerySet and
> other high-level APIs.
>
> As such, it's very difficult to change, and it may well be beyond our
> ability to successfully refactor.
>
> Switching to SQLAlchemy would force us to rewrite this code, which is
> for our own good. In addition, large chunks of it can be dropped
> entirely (i.e. most of database specific stuff). This will reduce our
> maintenance load going forward (eventually).
>
> (BTW, I'm not saying that we should let the existing code continue to
> rot, we should of course try to clean it up as best we can, and that
> effort is not wasted - I'm talking about a longer term strategy here.
> If we can refactor this code, great - this motivation can be dropped
> from the list, but I think the others still stand).
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.
What SQLAlchemy could do for us is generate the actual SQL. We would
probably never need to worry about things like how to generate proper
LIMIT queries for different backends, nor would we need to worry about
proper escaping etc. Hopefully we could get rid of most of the dirty
details of supporting different dialects of SQL. This and support for
more backends is reason enough to support this idea. DDL would be a
big bonus, too.
As said, I don't know SQLAlchemy well, so it might be it does more
things usable for our ORM. If so, even more reason to use it.
In addition, I would love if I could do first some operations using
Django's query API, then say "qs.as_sqlalchemy()" and then use
SQLAlchemy for those operations Django's ORM doesn't support.
So, count me in as +1 for this idea. I would not be surprised if it
turns out this will add complexity instead of reducing it. Still, to
me this seem promising.
- 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.
