Rendered at 09:53:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rcleveng 11 hours ago [-]
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.
listenallyall 11 hours ago [-]
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.
zshrdlu 2 hours ago [-]
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.
teamolHuang 9 hours ago [-]
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.
BadBadJellyBean 10 hours ago [-]
Did someone force you to use SQLAlchemy? I mean you can write DB queries with and ORM. There are also other ORMs for python.
listenallyall 9 hours ago [-]
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.
Daishiman 10 hours ago [-]
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.
scorpioxy 9 hours ago [-]
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.
listenallyall 10 hours ago [-]
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.
Daishiman 9 hours ago [-]
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.
listenallyall 6 hours ago [-]
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.
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.
Other aspects of it are fine, but this exact part strongly feels doing something un-python in python for me.
Tale as old as time.
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.