I may be in the minority here (based off of other comments), but using raw SQL commands has been more performant, easier to write, easier to understand, easier to learn, and easier to build complex queries/ commands than an ORM has ever provided.
Updating some records in a CTE and using the results in a subsequent SELECT? It may take a minute or so on stack overflow, but significantly less than it would with SQLAlchemy.
Want to make a composite primary key? I have no idea how you would do it with most ORMs, but it’s relatively straightforward with SQL.
A lot of times the stuff you want to do won’t even be available in your ORM, but the person lobbying for using it always pleads “it’s okay, it still allows you to make raw queries! We have an escape hatch!” Then when you start writing raw queries, your PRs get rejected: “Please stick to the ORM”.
I don’t understand people’s love of ORMs instead of simply learning SQL, it seems to bring on myriad headaches for nearly zero benefit.
I don’t use ORM, but depending on the complexity of the SQL statement I might build it using SQL alchemy core. I hate to deal with all these rules about the right way of escaping SQL Colum names with “, ‘ and [. I find it sqlalchemy core to be the right balance where I am still in charge of the transaction management around the statement but rely on a library to build the textual SQL statement, without it I would probably have to reinvent some parts of sqlalchemy.
> I don’t understand people’s love of ORMs instead of simply learning SQL
> Want to make a composite primary key? I have no idea how you would do it with most ORMs,
Since you mentioned SQLAlchemy
class MyTable(Base):
col1 = sa.Column(sa.Integer, primary_key=True)
col2 = sa.Column(sa.Integer, primary_key=True)
ORMs aren't an alternative to learning SQL.
* Type safety on all SQL operations.
* All the benefits of a query builder.
* Reverse relationships that read better in code `parent.children`.
* External file management that is generic, works on all your tables the same way, and supports multiple simultaneous back-ends making migrations easy.
* Object de/serialization and transformations letting you use native types like datetime.
* Typed/parsed JSON columns, I use Pydantic for this.
* Handling single/multi table inheritance for you and giving you type safety.
Updating some records in a CTE and using the results in a subsequent SELECT? It may take a minute or so on stack overflow, but significantly less than it would with SQLAlchemy.
Want to make a composite primary key? I have no idea how you would do it with most ORMs, but it’s relatively straightforward with SQL.
A lot of times the stuff you want to do won’t even be available in your ORM, but the person lobbying for using it always pleads “it’s okay, it still allows you to make raw queries! We have an escape hatch!” Then when you start writing raw queries, your PRs get rejected: “Please stick to the ORM”.
I don’t understand people’s love of ORMs instead of simply learning SQL, it seems to bring on myriad headaches for nearly zero benefit.