Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd say getting SQLAlchemy instead of the terrible Django ORM is enough of an advantage.

However, I have also found the tools around Django's ORM to be quite useful (admin, south).



You can use SQLAlchemy with Django.

The part I really like about Flask is the decorators for routes. This is how it should be, not some messy file of reg-exes.


You can sort of maybe use SA with Django, except when all the apps you use depend on it and you have to use SA reflection to get at your data. Sadly, the integration is poor.

I totally agree about the regexes: only a small subset of all routes will ever need regexes, and you can do it explicitly in Flask when needed.


Hehe. I prefer the regexes. More power, and I've used them for decades.


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.


I 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.


But 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.


That 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.


There 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.


Could you give a specific example? I'd be curious to see one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: