4 ms·

I find that the best of both worlds is to use something like sqlx for rust [1], which does compile time checking (using postgres explain analyze!) of the querie

I find that the best of both worlds is to use something like sqlx for rust [1], which does compile time checking (using postgres explain analyze!) of the queries and macros for static typing, but still let you write the query raw (and can be turned off completely by removing the trailing macro `!` as an escape hatch) We use it extensively for Windmill (e.g: [2]) and couldn't be happier. [1]: https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx [2]: https://github.com/windmill-labs/windmill/blob/d60a770eb710ed3234c77e7da794fe3e0dc13ea4/backend/windmill-api/src/apps.rs#L318 https://github.com/windmill-labs/windmill/blob/d60a770eb710e...

jchw 4y ago
I mainly checked out sqlx as it seemed like compile-time checked queries gave some of the advantages of sqlc in Go. However, I was a bit disappointed. Compile time checking requires you to connect to a database at compile time, with the schema already set up. Sqlc doesn't even require this at codegen time in Go, at the cost of needing to emulate some of the underlying database behaviors. I'm sure it's not a deal breaker to everyone, but I find the premise of needing a database to make queries against for every single build to be way, way, way too much baggage. The idea of checking the queries against a schema is great. Even better if you can use it to infer arguments and return types.
- rubenfiszel 4y ago
  I can see where this would be inconvenient. I write the migrations first so it doesn't bother me, but for prototyping it sure seems cooler to not even require the schema to exist.
- norman784 4y ago
  There's an offline feature that > Enables building the macros in offline mode when a live database is not available (such as CI) [0] [0] https://github.com/launchbadge/sqlx/blob/76ae2865005cc79d56972d68d3be30805581103d/README.md?plain=1#L182-L183 https://github.com/launchbadge/sqlx/blob/76ae2865005cc79d569...
moonchrome 4y ago
My problem with this approach is that you must have a database available during build time and autocomplete/real-time tooling usually gets messed up. Is this not a problem in the rust implementation ?
Pepe1vo 4y ago
Maybe I'm holding it wrong, but my experience with sqlx is a bit more lukewarm. It's really great that compilation success means that you didn't fuck up any queries, but... there's just SO much boilerplate. I find that due to Rust's extremely strict type system, I have to create dedicated record structs for all of my domain models representing how a model is stored in the database. So once everything's up and running it almost always implies there's essentially no bugs, but man is getting there a drag. Also, testing is quite a drag. If you're using sqlite, you can use in-memory mode and that's quite nice. But for other databases you basically have only two options: 1. setup and teardown an actual testing db 2. wrap your sqlx interfacing code in something vaguely resembling the repository pattern and create an in-memory implementation for testing. I'd call both of these options less than ideal. At work we predominately use TypeOrm, which for all its (many, many) faults is really ergonomic and succinct. So maybe my views of ORMs is just warped.

jchw 4y ago

I mainly checked out sqlx as it seemed like compile-time checked queries gave some of the advantages of sqlc in Go. However, I was a bit disappointed. Compile time checking requires you to connect to a database at compile time, with the schema already set up. Sqlc doesn't even require this at codegen time in Go, at the cost of needing to emulate some of the underlying database behaviors. I'm sure it's not a deal breaker to everyone, but I find the premise of needing a database to make queries against for every single build to be way, way, way too much baggage. The idea of checking the queries against a schema is great. Even better if you can use it to infer arguments and return types.

rubenfiszel 4y ago
I can see where this would be inconvenient. I write the migrations first so it doesn't bother me, but for prototyping it sure seems cooler to not even require the schema to exist.
norman784 4y ago
There's an offline feature that > Enables building the macros in offline mode when a live database is not available (such as CI) [0] [0] https://github.com/launchbadge/sqlx/blob/76ae2865005cc79d56972d68d3be30805581103d/README.md?plain=1#L182-L183 https://github.com/launchbadge/sqlx/blob/76ae2865005cc79d569...

moonchrome 4y ago

My problem with this approach is that you must have a database available during build time and autocomplete/real-time tooling usually gets messed up. Is this not a problem in the rust implementation ?

Pepe1vo 4y ago

Maybe I'm holding it wrong, but my experience with sqlx is a bit more lukewarm. It's really great that compilation success means that you didn't fuck up any queries, but... there's just SO much boilerplate. I find that due to Rust's extremely strict type system, I have to create dedicated record structs for all of my domain models representing how a model is stored in the database. So once everything's up and running it almost always implies there's essentially no bugs, but man is getting there a drag. Also, testing is quite a drag. If you're using sqlite, you can use in-memory mode and that's quite nice. But for other databases you basically have only two options: 1. setup and teardown an actual testing db 2. wrap your sqlx interfacing code in something vaguely resembling the repository pattern and create an in-memory implementation for testing. I'd call both of these options less than ideal. At work we predominately use TypeOrm, which for all its (many, many) faults is really ergonomic and succinct. So maybe my views of ORMs is just warped.