[bootsmann]

Only tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.

[globular-toast]

Have you sat down and read the SQLAlchemy docs properly? It made a lot more sense to me once I'd set aside an hour or two to work through the Unified Tutorial.[0] I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy.

If you know the SQL you want it's just a matter of writing it in SQLAlchemy's query language which is quite close to SQL. Should just be a matter of practice to become fluent in it. "Complex queries" usually turn up when you're doing something like rendering a table or report or something. You don't need the ORM for this kind of thing, just write a query.

An ORM is useful when you want to write domain logic to do read/write operations against domain entities and persist them back to a database. IMO people get hung up on ORMs and think if they're using one then they have to use it for everything then do the most horrible contortions that should have just been db queries. SQLAlchemy allows you to use the ORM judiciously.

[0] https://docs.sqlalchemy.org/en/20/tutorial/index.html

[9dev]

> I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy.

Good documentation should absolutely provide a usable reference to quickly look up common ways to solve common problems. Even the PHP docs got that right twenty years ago.

Also, I disagree: A library should be as self-evident and incrementally understandable as possible, not require reading a full tome and grow a grey beard before being accessible.

> "Complex queries" usually turn up when you're doing something like rendering a table or report or something. You don't need the ORM for this kind of thing, just write a query.

Or, when building generic filtering/sorting/pagination logic for a bog-standard CRUD app. Or to do full-text search. Or when doing lateral joins to minimize queries. Or to iterate over a huge table. There's lots of cases where I want the ergonomics and malleability of ORM query instances even when working with complex queries.

[johnfn]

> I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy.

In defense of OP, a particular frustration I have with SQLAlchemy is that I understand SQL just fine, but the ways in which I translate my SQL knowledge into SQLAlchemy incantations is often pretty obscure. I think I deserve "quick answers to do very specific things" because I already have the exact form of the SQL solution in my head. That it then takes 20 minutes of digging through docs or ChatGPT is annoying.

[tinodb]

Exactly the reason I stay away from it. I prefer just SQL and something like aiosql to load it.

[WD-42]

Yes. It’s super opaque. SqlAlchemy is one of those libs I want to like but the docs just make it too difficult.