SQLAlchemy is the library that convinced me, 8 or 9 years ago, to avoid using Python altogether.* Cold turkey, hard stop. Thank you for the motivation.
Not sure how they took something relatively straightforward - running database queries - and turned into such a convoluted mess.
*Python is still pretty good for data analysis, plotting, and scripting. But not for building actual applications.
Having used it in a code-base that had a lot of business logic and objects, I don't mind it at all. It's a transpiler is all. Plus at no point were we married to it, you could generate your query any which way you please, or even hand-craft them if it was getting in your way or your mood shifted.
Yea, I used the psycho-pg (yes I know thats not the right spelling) often. But that is postgres-specific. Tried other alternatives too. I'm sure it is better now, but those 2 were the dominant approaches back then. Obviously I had other issues with the Python language and ecosystem, but of all the pain points, SQLAlchemy was the worst of them.
Agreed, writing db queries in Python is just plain pain compared to C# + EF. Loved how I have to handle runtime type errors for SQLAlchemy queries in a dynamically typed language.
Other aspects of it are fine, but this exact part strongly feels doing something un-python in python for me.
They all say that until your business logic is so convoluted that maintaining several dozen SQL queries begets more work than sensible so you end up inventing your own query builder which is fine until you realize you really need business objects so you make up your own ORM and then you realize you needed SQLA or some similar piece of tech all along.
I agree and I've seen a similar argument a few times before. All of those times had the same ending.
SQLAlchemy is a beast for sure. But the complexity is not for fun. It gives you a lot in return. If your needs are simple, it's probably overkill. And this library is not for running queries, it's an ORM. Which has a component that will eventually need to send the queries to the database but it's a lot more than that.
I don't disagree that it's tremendously overpowered. You can use SQLModel with FastAPI if you want a more minimal API surface that uses SQLA under the hood. As a user I just don't have to deal with most of its complexity on a day to day basis so it doesn't bother me and I don't think it's a bad end state for a swiss-army knife of a query library.
Well, neither SQLModel nor FastAPI existed at the time. So those weren't really options. And SQLAlchemy was still many years away from v2. So whatever it has done in the meantime to improve (I honestly have no idea) was not part of the library at the time.
im usually thrilled when people look at SQLAlchemy and run screaming...because if these people stick around and are my actual users (which does happen, since folks are at work sometimes), they are of course miserable and typically insufferable.
but making a decision about Python overall based on SQLAlchemy, wow I should be flattered that someone would think SQLAlchemy's has captured "Pythonic" so perfectly that we're the canonical example of it. But no, in Python, SQLAlchemy is definitely its own thing. You'd want to look at Django for pretty much the opposite take on everything (again, super awesome. people like django! great! you don't want to be my user, that's for sure!), all while staying well within Python's pretty amazing ecosystem and community.
I'm super excited to get rid of all of my workarounds that add or remove `+psycopg` from the URLs depending on what I'm giving it to.
SQLAlchemy is the library that convinced me, 8 or 9 years ago, to avoid using Python altogether.* Cold turkey, hard stop. Thank you for the motivation.
Not sure how they took something relatively straightforward - running database queries - and turned into such a convoluted mess.
*Python is still pretty good for data analysis, plotting, and scripting. But not for building actual applications.
Having used it in a code-base that had a lot of business logic and objects, I don't mind it at all. It's a transpiler is all. Plus at no point were we married to it, you could generate your query any which way you please, or even hand-craft them if it was getting in your way or your mood shifted.
Did someone force you to use SQLAlchemy? I mean you can write DB queries with and ORM. There are also other ORMs for python.
Yea, I used the psycho-pg (yes I know thats not the right spelling) often. But that is postgres-specific. Tried other alternatives too. I'm sure it is better now, but those 2 were the dominant approaches back then. Obviously I had other issues with the Python language and ecosystem, but of all the pain points, SQLAlchemy was the worst of them.
Agreed, writing db queries in Python is just plain pain compared to C# + EF. Loved how I have to handle runtime type errors for SQLAlchemy queries in a dynamically typed language.
Other aspects of it are fine, but this exact part strongly feels doing something un-python in python for me.
They all say that until your business logic is so convoluted that maintaining several dozen SQL queries begets more work than sensible so you end up inventing your own query builder which is fine until you realize you really need business objects so you make up your own ORM and then you realize you needed SQLA or some similar piece of tech all along.
Tale as old as time.
I agree and I've seen a similar argument a few times before. All of those times had the same ending.
SQLAlchemy is a beast for sure. But the complexity is not for fun. It gives you a lot in return. If your needs are simple, it's probably overkill. And this library is not for running queries, it's an ORM. Which has a component that will eventually need to send the queries to the database but it's a lot more than that.
You're not entirely wrong. But SQLAlchemy's approach and design are still awful and confusing. There are much, much better tools/libraries out there.
I don't disagree that it's tremendously overpowered. You can use SQLModel with FastAPI if you want a more minimal API surface that uses SQLA under the hood. As a user I just don't have to deal with most of its complexity on a day to day basis so it doesn't bother me and I don't think it's a bad end state for a swiss-army knife of a query library.
Well, neither SQLModel nor FastAPI existed at the time. So those weren't really options. And SQLAlchemy was still many years away from v2. So whatever it has done in the meantime to improve (I honestly have no idea) was not part of the library at the time.
im usually thrilled when people look at SQLAlchemy and run screaming...because if these people stick around and are my actual users (which does happen, since folks are at work sometimes), they are of course miserable and typically insufferable.
but making a decision about Python overall based on SQLAlchemy, wow I should be flattered that someone would think SQLAlchemy's has captured "Pythonic" so perfectly that we're the canonical example of it. But no, in Python, SQLAlchemy is definitely its own thing. You'd want to look at Django for pretty much the opposite take on everything (again, super awesome. people like django! great! you don't want to be my user, that's for sure!), all while staying well within Python's pretty amazing ecosystem and community.