ORM roadmap
Thierry
I know this is not a problem for most users. But when working with
complex projects or projects requiring some performance optimization
django orm doesn't suffice. Its a pity to see strong development on
django orm, while at the same time the sqlalchemy project has huge
traction. I currently run both orm's. The gap between sqlalchemy and
django orm is very large. Are there any plans to integrate sql
alchemy?
Alex Gaynor
own ORM if we planned to throw it away. There have been external
projects to integrate SQL Alchemy into Django, but I hvae no idea what
the status of them is.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
James Bennett
> I know this is not a problem for most users. But when working with
> complex projects or projects requiring some performance optimization
> django orm doesn't suffice. Its a pity to see strong development on
> django orm, while at the same time the sqlalchemy project has huge
> traction. I currently run both orm's. The gap between sqlalchemy and
> django orm is very large. Are there any plans to integrate sql
> alchemy?
In a word, no.
There are several reasons, some quite independent of each other, for
Django having its own ORM and trusting that people who don't like it
or want/need something else will take advantage of the fact that
Django's just Python, and will use whatever ORM solution they prefer.
First, and dearest to my heart as release manager, is simply that a
move toward SQLAlchemy would be large enough and disruptive enough
that we couldn't in good faith do it during the Django 1.x release
series; if it were to happen at all, it'd have to happen at a bump of
the major version number (e.g., in a move from a Django 1.x -> Django
2.x).
You'll notice, for example, that even something as tiny as switching
``AdminSite.root`` to an include of ``AdminSite.urls`` is going to
need multiple full release cycles to complete, because we have a
strong commitment to API compatibilty and stability, and so follow the
same general process as Python itself for deprecating and removing
pieces of API. Given what's involved even in a tiny change like the
admin URLs, it should be fairly clear that we simply could not switch
ORMs midstream in a release series even if we wanted to.
Second, I don't particularly think there's a major need to try to make
everyone converge on one single ORM, or even as large a community
impetus as you may suspect; there are, right now, either four or five
(depending on how you want to count) major Python ORM projects with
decent community support, and none of the others seem to be
particularly interested in abandoning their efforts (or even feeling
any particular pressure to do so) in favor of a merge with SQLAlchemy.
Third, and somewhat related to the above, I don't think it would be a
good thing for Django to do this; SQLAlchemy is a very good ORM,
certainly, but it also has a certain approach to and assumptions about
ORM which are very deeply and very rigidly embedded into it. It is,
fundamentally, a Data Mapper-style ORM, and that will practically
always be visible and have effects on end user code even with
extensions designed to emphasize a different approach. Django's ORM,
meanwhile, has its own approach and assumptions which are, again,
rather deeply and solidly built in; it is, fundamentally, an Active
Record-style ORM, and that will practically always be visible and have
effects on end-user code.
And this is not a bad thing! Both of these are valid, respectable
approaches to the ORM problem, and personally I think the Python
ecosystem would be poorer, not richer, if one of these approaches were
to be eliminated. Right now Django and SA represent the "best of
breed" implementations of these approaches, and in order to keep good
implementations available I think the Django ORM needs to continue to
be developed and supported.
Fourth, it's worth noting that we have certain stated goals for what
we'd like our ORM to do, and those goals are irreconcilably
incompatible with stated goals of SQLAlchemy. For example, it is a
goal of Django's DB layer to eventually support backends which are not
SQL databases (e.g., the BigTable implementation in Google App Engine,
CouchDB, etc.). So far as I know, however, SQLAlchemy has stated
unequivocally that they will remain SQL-only.
I could probably go on for a while here, but hopefully it's clear by
now that there are some fairly solid arguments for Django continuing
to maintain and use its own ORM solution instead of switching to
SQLAlchemy (or any other project which might come along and gain
similar traction -- it's useful to remember that, in the beginning,
emails such as yours asked why we didn't just switch to SQLObject,
since that was at the time the standard default ORM in other major
frameworks; had we done so we'd have been in a bit of a pickle when
everybody abandoned it).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Russell Keith-Magee
>
> On Sat, Oct 3, 2009 at 1:58 PM, Thierry <thierrysc...@gmail.com> wrote:
>> I know this is not a problem for most users. But when working with
>> complex projects or projects requiring some performance optimization
>> django orm doesn't suffice. Its a pity to see strong development on
>> django orm, while at the same time the sqlalchemy project has huge
>> traction. I currently run both orm's. The gap between sqlalchemy and
>> django orm is very large. Are there any plans to integrate sql
>> alchemy?
>
> In a word, no.
To put in one more voice of authority - speaking as a core developer,
I'm strongly opposed to modifying Django to use SQLAlchemy (or any
other external project for that matter) as the ORM.
On top of the many valid reasons that James mentioned, there is one
more that I consider to be very important - one that stems from the
task that _any_ ORM is trying to perform.
The goal of any SQL-backed ORM is to provide a syntax that makes it
easy to express SQL queries. The problem is, we already have a very
powerful, 100% feature complete syntax for expressing SQL queries -
it's called SQL. By very definition, _every_ SQL-backed ORM is
reinventing the wheel.
ORMs have an important role to play in making the simple cases very
simple - and this is a sweet spot that Django's ORM, SQLAlchemy, and
any number of other ORM projects manage quite well. It is much easier
to write "Author.objects.all()" than to write "SELECT id, firstname,
lastname, birthdate, address1, address2, .... FROM author".
However, this argument isn't about the simple cases - it is about the
complex cases. I will certainly grant that SQLAlchemy is certainly
able to cover more of the world of possible SQL queries than Django's
ORM. However, there are queries that even SQLAlchemy can't express (or
can't express elegantly). At this point, you can either continue
making modifications to your non-SQL language in an attempt to provide
100% coverage of the SQL spec, or you can step back and say "No - we
already have a language that does this", and embrace it.
Django has decided to take the latter approach. The recent proposals
for a raw() operator to make it easier to return Django model objects
as the result of a raw SQL query is an expression of this underlying
philosophical direction.
So, no - for this reason, and many many others, we're not going to
adopt SQLAlchemy as Django's ORM.
That said, we are committed to making it easier to use non-Django
components inside a Django project. If there is anything that we can
do to make it easier to use SQLAlchemy (or any other non-Django ORM)
inside a Django project, we're open to those suggestions.
Yours,
Russ Magee %-)
Thierry
I appreciate it.
I find an orm usefull for 3 scenarios:
1. - simple object retrieval posts.objects.all()
2. - performance optimized object retrieval, your raw approach would
suffice here
3. - generating complex queries, and reusing sql components
When you get to complex data models, Django currently fails on 2 and
3.
Agreed though, I guess only a handful of apps encounter these
problems.
On Oct 4, 6:27 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 5:00 AM, James Bennett <ubernost...@gmail.com> wrote:
Tim Chase
> 1. - simple object retrieval posts.objects.all()
> 2. - performance optimized object retrieval, your raw approach would
> suffice here
> 3. - generating complex queries, and reusing sql components
> When you get to complex data models, Django currently fails on 2 and
> 3.
I'd agree and elaborate on #1, that ORMs are good for simple
object retrieval, and also for eliminating some of the most
grievous cross-platform issues.
However, I must disagree on #2 and #3: I'd never consider the
*addition* of a generalization-layer (an ORM in this case, but
the idea is far more broadly applicable) a step towards
optimization. Likewise, for my more complex queries, there's no
good way to express them efficiently in *any* ORM I've used --
many end up either inexpressible, or they involve bringing back
gobs of data client-side and post-processing it there instead of
at the server.
I use an ORM for the same reason I use Python: they make common
tasks easy. Using Python/ORM, I can bang out most of what I
need. But when I hit a wall (performance or complexity), both
need to allow be to go *down* a layer (to C or SQL).
So I'd say Django has done a fine job of making the ORM what it
should be -- an approachable, cross-platform, cross-database
data-access layer that covers most use-cases and gets out of your
way when you need it to.
-tkc