4 ms·

You put it better than I could. There are certainly naive examples of how to use it out in the wild but that's not SQLAlchemy's fault. It's a sophisticated tool

You put it better than I could. There are certainly naive examples of how to use it out in the wild but that's not SQLAlchemy's fault. It's a sophisticated tool that accurately reflects how a database works. I caution people against using Django because the ORM makes so many weak, simplified assumptions about how a database works that don't bear out in practice. It's fine for a blog. It falls apart when you're working with Real Data.

kennydude 6y ago
I've used Django with "real data", as in accountancy software for multiple years of transactions across 200+ fairly large clients and it's absolutely fine. Whereas I've used Sqlalchemy and getting it to do a basic join, turns out there's 3 different ways of doing it all with an insane amount of crap to find the right way of doing things. I actually left my old job in part due to Sqlalchemy being too painful to work with.
- BiteCode_dev 6y ago
  There is absolutely a lack of a decent SQLA tutorial for IRL code. The doc is very formal, and if you want to make a website, a quick script or a data migration, you are left on your own to find the proper setup.
- ergo14 6y ago
  Like... Query.join(), https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying-with-joins https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying... .
- WesleyJohnson 6y ago
  I use Django with "real data" as well and, generally, it's pretty good once you learn how to wield it. My biggest issues are lack of multi-column primary keys and inefficient queries when doing .count(), that often introduce unnecessary group by statements in the subquery. If either of those could be addressed, I'd enjoy it so much more.
orf 6y ago
What weak assumptions does it make?
dguaraglia 6y ago
Django is optimizing for the 99.99% of people rather than the 0.01% of people who manage billions of rows on a single table. I like SQLAchemy, but for most people the added cost of managing connections, transactions, have to decide whether to use the 'ORM' or not, manually having to 'commit' changes, eager-loading vs. lazy-loading, is a complete waste of time if all they want is a website that will be used by - at best - a couple hundred people concurrently.

kennydude 6y ago

I've used Django with "real data", as in accountancy software for multiple years of transactions across 200+ fairly large clients and it's absolutely fine. Whereas I've used Sqlalchemy and getting it to do a basic join, turns out there's 3 different ways of doing it all with an insane amount of crap to find the right way of doing things. I actually left my old job in part due to Sqlalchemy being too painful to work with.

BiteCode_dev 6y ago
There is absolutely a lack of a decent SQLA tutorial for IRL code. The doc is very formal, and if you want to make a website, a quick script or a data migration, you are left on your own to find the proper setup.
ergo14 6y ago
Like... Query.join(), https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying-with-joins https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying... .
WesleyJohnson 6y ago
I use Django with "real data" as well and, generally, it's pretty good once you learn how to wield it. My biggest issues are lack of multi-column primary keys and inefficient queries when doing .count(), that often introduce unnecessary group by statements in the subquery. If either of those could be addressed, I'd enjoy it so much more.

orf 6y ago

What weak assumptions does it make?

dguaraglia 6y ago

Django is optimizing for the 99.99% of people rather than the 0.01% of people who manage billions of rows on a single table. I like SQLAchemy, but for most people the added cost of managing connections, transactions, have to decide whether to use the 'ORM' or not, manually having to 'commit' changes, eager-loading vs. lazy-loading, is a complete waste of time if all they want is a website that will be used by - at best - a couple hundred people concurrently.