Will Larson just created a post titled Replacing Django’s ORM with SQLAlchemy that covers using SQLAlchemy with a Django project. It’s a great write-up, and generally what Django folks are referring to when they say, “of course you can use SQLAlchemy with Django.” I think Will does a good job of stepping you through the important bits.
One thing I appreciate is that the post hints at some of the negatives of doing something like this. You lose things like generic views, all contrib apps including the admin, most of the management commands, and some smaller pieces that are embedded in various parts of the framework. Tread this way cautiously.
Another item in the post that got my attention was when Will mentioned the following in reference to the possibility of doing a full drop in replacement for the Django ORM, essentially allowing you to use fully the Django bits alongside of the SQLAlchemy pieces:
This tutorial won’t build that Frankenstein, since it’s only interested in exploring the loose coupling aspect, but it wouldn’t be prohibitively difficult to do so. Although, it would be awkward in some regards.
Well I, and others, have been building “that Frankenstein” for some time now with a project we call Django-SQLAlchemy. There’s also a somewhat defunct project called Tranquil that is a hybrid between what Will demonstrates and what we’re trying to do with django-sqlalchemy.
I’m not sure whether or not these projects are “awkward” or “Frankensteins,” but I can assure you thus far they have been prohibitively difficult, as we see no full implementation for a drop-in replacement still today. Getting the initial stuff in place is pretty darn easy, but as you get into it there are lots of little edge cases that complicate things significantly.
I want to thank Will for the great post. I think he does a great job of talking about the strengths of SQLAlchemy, and hopefully people will be inclined to experiment with the idea of using SQLAlchemy in addition to, or instead of, Django’s ORM.
I still think that replace the Django’s ORM completely with SQLAlchemy (like the Will Larson’s post) and replace also the parts of Django that use the standard ORM (general views and apps) require the same development time for the Django-SQLAlchemy project.
I played with the code of the Django’s ORM and, IMHO, is too difficult to expand and integrate with others ORM.
Actually is not possible to use an external ORM in a reasonable manner. The solution is to implement an interface (a declarative layer like Elixir) in Django in order to separate the ORM, so it is possible to change it easily and use the actual ORM like an external one.
This solution resolve four items: - people can use the ORM that the job require; - maintain a compatibility of models between ORMs; - Django still have a standard ORM without dependencies; - less development efforts in order to maintain the compatibility for the external ORMs.
I see only a cons: perfomances (IMO just a little difference). But it is possible to remove the declarative layer in order to have better performances (replacing also the models like the actual solutions).
The problem is in the hands of the actual Django-ORM mantainer, whatever it is the solution.
So, uh, what’s wrong with Django’s ORM? I don’t get it.
Mark: There’s nothing wrong with it. It’s just that sometimes people have use cases that extend outside of the functionality provided by the built in ORM. For instance if you want to do sharding you’re not going to get that with Django’s ORM. Yet sharding is readily available in SQLAlchemy. Again it’s not a wrong or right, or good or bad thing.
Exactly :)
The Django ORM is easy to use but too limited for the 30% of my uses. Other people develop in Django for simple features so the Django ORM is enough.