One huge benefit of an ORM is that it does type checking. it makes sure your tables exist, relationships are valid, etc, and it makes easy things easy. If you add a column, it’ll make sure it gets populated, give you decent error messages, etc.
As long as you use a proper repository pattern setup and isolate DB interactions from the rest of the code, how you construct the queries is completely up to you. I try to use DTOs to communicate w/ the repo layer, so whether an ORM is used or direct SQL queries is largely an implementation detail.
Not an ORM, but uses Rust’s compile time macros so you can write raw SQL and it will type check everything against either a real database connection or a JSON cache of the database’s schema.
No, just write a repository to expose domain operations and implements them using SQL directly. Trying to fake OO object graphs against a RDBMS with a super-complex and leaky ORM is just painful.
Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.
To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.
ProfitI’m confused. Are you saying all of that is a consequence of not using ORMs? Because if so, that’s absolutely not true. ORMs truly are complete trash.
Sounds like you were hurt by an ORM.
One huge benefit of an ORM is that it does type checking. it makes sure your tables exist, relationships are valid, etc, and it makes easy things easy. If you add a column, it’ll make sure it gets populated, give you decent error messages, etc.
As long as you use a proper repository pattern setup and isolate DB interactions from the rest of the code, how you construct the queries is completely up to you. I try to use DTOs to communicate w/ the repo layer, so whether an ORM is used or direct SQL queries is largely an implementation detail.
https://github.com/launchbadge/sqlx
Not an ORM, but uses Rust’s compile time macros so you can write raw SQL and it will type check everything against either a real database connection or a JSON cache of the database’s schema.
Absolute best of both worlds.
That sounds really nice, I’ll have to check it out.
No, just write a repository to expose domain operations and implements them using SQL directly. Trying to fake OO object graphs against a RDBMS with a super-complex and leaky ORM is just painful.
Would you classify GORM that way?
Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.
To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.
GORM is Go ORM
I have not used that GORM, but ORMs have those problems generally.
i prefer going GORMLESS
I have for years been pumped to create a sql only side project or sql + frontend
Please don’t. I self-host actual budget, and they compile SQLite to WASM to use it in the FE. That just feels… wrong.
https://github.com/PostgREST/postgrest
There are some other options as well: https://youtu.be/3JW732GrMdg