On Sat, Oct 3, 2009 at 1:58 PM, Thierry <thierryschellenb...@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. 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." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
