> 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.
Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
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.
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).
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.
You would rather inline them into a single nested magical variable name instead?