5 ms·

How does SQLAlchemy compare to the Django ORM (if it would be a stand-alone package, which it sadly isn't)?

• ddorian43 11y ago
  Things that I've used in sqlalchemy that(by a quick search) aren't in django (as far as I know): composite primary keys complex indexes (functional etc) arrays + json(these are in django, but I think only recently and before that in contrib) server side cursors the non-orm part(the lower layer) sqlalchemy-alembic (also in django, but only recently I think, still probably less features) server_default (define a default value for a column that will be applied to the sql-schema and not just model.field) more customization to the lower level db driver(psycopg2, maybe this is also supported in django) Use the models + library outside of your web app (ex: in several non-request-serving processes ) There are alot more features that I haven't used/don't know/didn't need.
  • andybak 11y ago
    A few minor points: 1. Django's built in migrations are essentially South 2.0 and a poster above implied that South was more featureful than Alembic. I couldn't say for sure. 2. "Use the models + library outside of your outside of your web app" - not sure why this can't be done with the Django ORM? I use the ORM for many background and batch tasks It would be interesting to know What SQLA afficianodos think of the new goodies in Django 1.7/1.8: https://docs.djangoproject.com/en/1.8/ref/models/conditional-expressions/ https://docs.djangoproject.com/en/1.8/ref/models/conditional... https://docs.djangoproject.com/en/1.8/releases/1.8/#query-expressions-conditional-expressions-and-database-functions https://docs.djangoproject.com/en/1.8/releases/1.8/#query-ex... https://docs.djangoproject.com/en/1.8/releases/1.7/#custom-lookups https://docs.djangoproject.com/en/1.8/releases/1.7/#custom-l... Obviously the main reason to love the Django ORM is it's tight integration with Django but I think nowadays it's rather undeserving of it's "SQL Alchemy's poor cousin" reputation.
• marcosdumay 11y ago
  SQLAlchemy gives you a lower level view of your data. That makes a lot of issues with Django ORM just go away (like slow queries for null foreign keys), and makes the ORM much more powerful, making it possible to run queries that would need customizations of the Django ORM. At the price that it is lower level, and your code will be a bit longer. Both let you escape into bare SQL easily, and Django ORM integrates well with Django, what SQLAlchemy doesn't.
• TheSmoke 11y ago
  all the answers aside, imagine a complex SQL query that you can't possibly generate with Django ORM. well, SQLAlchemy will do that for you.
  • collyw 11y ago
    Is it worth it though? I have wrestled the Django ORM into doing some relativley complex queries, but looking back, I am not sure it is worth the effort. The code is more likely to be harder to undersatand by anyone except me, and I started with the equivalent SQL and tweaked the ORM version of the query until it worked. You still need to know the SQL that will be produced when you start using the extra clause. Maybe SQL alchemy is better. I guess I'll find out soon as my new workplace is using it.
    • TheSmoke 11y ago
      well, SQLAlchemy manages to keep the code pythonic and SQL oriented so it's worth it imho. check the core, you will like what it has to offer.
• antod 11y ago
  My flippant answer: Easy things are easier in Django. Harder things are easier (or even possible) in SQLA. But that's not quite accurate either, it's more a case of Django being a bit less work to get started with while SQLA needs a little more effort up front. But once set up and mapped, SQLA isn't any harder to use than Django.