4 ms·
> I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLA
by deaddodo 2y ago
> I've never heard anyone but a Rails dev complain that it's "too verbose".
Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
- kshahkshah 2y agoThat's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI
- agumonkey 2y agoyeah, alembic feels especially "small" and obscure compared to the hyper exhaustive nature of SQLA for everything else. felt like a side project at first
- gmassman 2y agoAlembic is certainly a bit of a challenge to grasp at first, especially if you want to do anything more complicated than create or alter tables. However, it does provide a great amount of flexibility if you want to implement more complex migration functionality. It allows library developers to add powerful features that would be very difficult to do with Rails/ActiveRecord or Django ORM. FWIW I maintain the flask-audit-logger package. It allows users to maintain audit logs of specific tables using postgres triggers. Being able to create custom migration operations is really an amazing feat. The alembic docs are quite dense, but the code is well organized and very readable.
- irjustin 2y agoYeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.
- globular-toast 2y agoNot to mention SQLAlchemy supports the unit of work pattern meaning you can update many objects at once. It tracks and figures out how to apply the updates all in one go. Django supports one object at a time. With SQLAlchemy it's easy to build mappers to real domain objects that are independent of the database. Most Django people treat the Django models as entities or, worse, do business logic in views etc. It's possible to implement unit of work on top of Django, but that's then another layer you have to maintain yourself (which SQLAlchemy does for you). But SQLAlchemy is harder. It's better but it's harder. Django is easier to get going with. But it bites you later (unless your app is just CRUD, in which case Django is all you need, well that and a better way to generate HTML).
- acdha 2y agoI class the SQLAlchemy unit of work pattern as one of the harder things: in the cases where Django’s bulk update mechanisms wouldn’t work, it’s extremely easy for someone who isn’t an SQLAlchemy expert to get confused about when changes are committed or to inadvertently leak sessions. It’s a powerful idea but having helped people with it I’ve mostly felt it reinforce my belief that less magic is usually better from a support perspective.
- aerhardt 2y agoTo each their own, nothing about the first syntax feels miserable to me, my IDE has got me fully supported on it. I don't dislike the SQL Alchemy one though it takes many more lines on my editor (no way I am going to inline all those nested dicts like that).