3 ms·
SQLAlchemy has pulled so far ahead of the Django ORM in features and usablility that I hope with the Django 3.0 release they replace their ORM with SQLAlchemy.
by megaman821 14y ago
SQLAlchemy has pulled so far ahead of the Django ORM in features and usablility that I hope with the Django 3.0 release they replace their ORM with SQLAlchemy. For all the basic use cases it is pretty easy to add in the Djangoisms to the SQLAlchemy ORM layer.
- andybak 14y agoI don't have the time to organize my thoughts but I would like to pipe up here and say that the it's not fair to call the Django ORM 'terrible'. It's extremely easy to learn and does a good job for a very large chunk of plausible use-cases.
- lucian1900 14y agoBut it does an absolutely terrible job for another pretty large chunk of use-cases, mostly because it's closer to objects than relations. For example, Django's ORM has no concept of explicit joins for example, which are necessary for avoiding O(n) # of queries in several cases. The only way to do it is to write SQL, whereas with SA the query is trivial to write in Python.
- andybak 14y agoCould you give a specific example? I'd be curious to see one.
- megaman821 14y agoThat is not true it is just that the syntax is non-obvious and awkward in my mind. You can do stuff like Teacher.objects.all().select_related('students') and Teacher.objects.filter(students__first_name='Jill'). The biggest frustration is aggregation though. It has hard and sometimes impossible to add group by and having clauses. Using extra() is very fragile and using values to force the group by is awkward. There is probably no fixing that part of the Django ORM other than just getting rid of it.
- lucian1900 14y agoThere are still joins that are not expressible through its syntax, like outer joins between several unrelated models. I've been pondering implementing a Django ORM backend that just delegates to the relevant SQLAlchemy functions. I think it may be way harder than it seems, though.