[megaman821]

Thanks for this release. Learning SQL before ever touching an ORM, SQLAlchemy's approach makes a lot more sense to me than something "simplier" like Django's ORM.

Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?

[zzzeek]

that idea has come up on many occasions and was seriously discussed some years ago. I don't think it's ever happening in that specific form; mostly because it would require that the Django ORM's behavior and usage contract not change at all in order to support backwards compatibility. This would be a very large task, at the very least for Django and probably for us as we make adjustments to support them. The feel and behavior of Django's ORM would invariably change quite palpably - even if you can get every function input and output to match, you still have what it looks like when you get a stack trace, an error message, etc. Django users would see lots of unfamiliar "sqlalchemy" lines in these stack traces and tracking down issues would then involve both Django and SQLAlchemy devs. Performance would also be a concern - keeping behavior exactly as is within Django might require some odd workarounds or additional logic which could prove to be complex and/or less performant.

That said, I have on occasion floated an alternative idea, which is to basically port the Django configurational and query system to SQLAlchemy entirely, doing away with full backwards compatibility and essentially providing a "transitional" platform, where you take an existing Django application and basically run it on top of a new ORM layer that actually uses the SQLAlchemy Session and unit of work model, but the majority of the Django configuration and queryset behavior remains available, thus making porting a relatively painless process (but still, there'd be a porting process). This approach has two advantages. One is, it's actually doable, we're providing a new platform and not trying to duplicate an existing one. The other is, we're actually delivering to a Django application some of the biggest advantages SQLAlchemy has, which are namely the ORM features like unit of work/identity map, the instrumentation model including collections and eager loading support, and inheritance support.

Nobody has time / motivation for that idea either, but I think if it ever happened, it would be more pragmatic.

[scardine]

The ORM is mediocre compared to SQLAlchemy, the template system is weak compared to Jinja2.

If you swap Django's ORM with SQLAlchemy and replace Django Templates with Jinja2, you end up with something like Flask.

The killer feature for me is Django's "admin" app. When I'm not using the "admin", the rest of Django kind of gets in the way. Nowadays I prefer a less opinionated framework like Flask if I'm not using the "admin".

Also, Django lacks any concept of multi-tenancy and does not support composite primary keys nor schemas, which makes it a poor choice for SaaS projects. That said, Django REST Framework is awesome for API-first development and makes it a whole different game (in a positive way).

[megaman821]

I don't think Django should ditch their ORM, but for the time being simply re-implement it on top of SQL Alchemy core.

I think it would have at least three positive outcomes:

* It would greatly increase support for the number of databases and database drivers.

* It would give developers something in between using the ORM or forgoing it and using SQL strings in raw() or db.connection().

* It would provide an easier path forward to adding additional capabilities into the Django ORM.

[tga]

In my experience the true killer feature of Django is the "batteries included" approach. If you stay within the boundaries of the framework you get a standard project structure, a decent ORM, a template language (dogmatically crippled, but that's a different discussion), a forms handling library, and the typical assorted framework toolkit (internationalization, logging, development server, utilities, etc) -- all equally documented and maintained. Compare this with having to choose and figure out individual libraries for every one of the things above, each coming with different levels and styles of documentation, communities, and resources.

The end result is that you spend less time deciding on small things and can just use what's in the box. The real value is that the next person working on the code is already on the same page and can start working with it a lot quicker.

[thezilch]

Nah, I'm not sure having all the libs bound together is the killer. I think it's having all those libs with a cohesive set of docks and with a "single" voice. I'm not sure that packaging Flask, Jinja2/Babel, WTForms, SQLAlchemy, and Werkzeug (dev / debug server) together -- that should cover the non-admin Django -- would improve the usage. Technically, Jinja2 and Werkzeug are already dependencies of Flask, and their extensions page [0] are fairly instructive on what other libs to pull in for the other needs. There's also no reason one can't use Django, Jinja2/Babel, WTF, SQLA, and Werkzeug... we do!

[0] http://flask.pocoo.org/extensions/

[phonon]

Django 1.7 will support composite keys (it's been worked on for several years.)

https://code.djangoproject.com/wiki/Version1.7Roadmap

[tga]

I don't see this ever happening because Django has no dependencies on any other Python libraries. It wouldn't make sense to start requiring SQLAlchemy only to reimplement the existing ORM on top of it for little to no benefit.

[megaman821]

That's not true. Django doesn't install any other libraries. It simply includes them in Django itself, like simplejson or six.

I think the packaging and setup tools are getting better so maybe it doesn't always have to be that way.

[tga]

I see what you mean, but arguably those aren't really dependencies if they are included in the Django tree. Also, it's definitely not something that would work with a large library like SQLAlchemy.

You can also see the "no dependencies" claim on the Django website: https://www.djangoproject.com/download/, it's a selling point.