51–60 of 109 posts
It is a query builder (not an ORM), that (ab)-uses the Typescript type system to give you full type safety, intellisense, autocomplete etc.
Crucially it doesn’t require any build/compile step for your queries which is fantastic.
There was a saying that before learning postgres in depth, the db is just a dumb store of data for devs, once you spend time to learn the tools it provides though, most applications just look like a very thin layer on top of the sql. There is so much more to rdbms (especially pg) than just joins - common table expressions, window functions, various views, let alone all the extensibility - extensions, custom types, ev…
This is what jOOQ does. Best SQL library I've ever used. https://www.jooq.org/
There was a saying that before learning postgres in depth, the db is just a dumb store of data for devs, once you spend time to learn the tools it provides though, most applications just look like a very thin layer on top of the sql. There is so much more to rdbms (especially pg) than just joins - common table expressions, window functions, various views, let alone all the extensibility - extensions, custom types, ev…
It would be great to have some sort of sql string to type parsing as some sort of plugin to TypeScript.
There was a saying that before learning postgres in depth, the db is just a dumb store of data for devs, once you spend time to learn the tools it provides though, most applications just look like a very thin layer on top of the sql. There is so much more to rdbms (especially pg) than just joins - common table expressions, window functions, various views, let alone all the extensibility - extensions, custom types, ev…
This is what jOOQ does. Best SQL library I've ever used. https://www.jooq.org/
Differences:
* jOOQ is an eDSL with an optional schema-to-classes generator
* you write jOOQ queries in Java (or Kotlin as we do)
* there's quite a bit of type-safety added when using the generator: the schema needs to be match the queries you write or you get compile errors
* jOOQ queries are built are run time adding a little overhead that sqlc does not
* writing jOOQ is very close writing SQL (a very thin abstraction), sqlc is "just SQL" it seems
Surprised nobody has mentioned “Kysely” ( https://kysely.dev ). It is a query builder (not an ORM), that (ab)-uses the Typescript type system to give you full type safety, intellisense, autocomplete etc. Crucially it doesn’t require any build/compile step for your queries which is fantastic.
(How does the IDE do the autocomplete on strings? Will the compiler also catch "bad strings"?)
Otherwise it looks much like jOOQ but without the "jOOQ generator" (which adds most of the type safety).
Earlier quoted context omitted.
This is what jOOQ does. Best SQL library I've ever used. https://www.jooq.org/
We use jOOQ, and love it. But sqlc also makes nice trade offs. I see it does Kotlin generation: if this lib was around when we picked jOOQ, I's certainly had considered it. Differences: * jOOQ is an eDSL with an optional schema-to-classes generator * you write jOOQ queries in Java (or Kotlin as we do) * there's quite a bit of type-safety added when using the generator: the schema needs to be match the queries you wri…
There was a saying that before learning postgres in depth, the db is just a dumb store of data for devs, once you spend time to learn the tools it provides though, most applications just look like a very thin layer on top of the sql. There is so much more to rdbms (especially pg) than just joins - common table expressions, window functions, various views, let alone all the extensibility - extensions, custom types, ev…
There was a saying that before learning postgres in depth, the db is just a dumb store of data for devs, once you spend time to learn the tools it provides though, most applications just look like a very thin layer on top of the sql. There is so much more to rdbms (especially pg) than just joins - common table expressions, window functions, various views, let alone all the extensibility - extensions, custom types, ev…
I didn't look forward to working with C# initially but Linq has been a fresh air since your statements more or less map 1:1 to SQL and probably quite overlooked because of "Microsoft"(and that Linq with old EF could have nasty surprises).
What people don't know/realize is that because Linq expressions in C# are left "uncompiled" they can be passed to the SQL layers and converted to idiomatic SQL, so you have all the typesafety of C# and regular C# code but get SQL code that is executed on the server (there is some minor impedance mismatch but it's minor enough and mainly with strings).
Migrated from GORM to sqlc. We like the code generation approach with the simplistic abstractions. https://github.com/helpwave/services/tree/main/services/task...
Imho ORMs are not worth it. Too much to learn (often through nasty surprises) for too little benefit.
Earlier quoted context omitted.
We use jOOQ, and love it. But sqlc also makes nice trade offs. I see it does Kotlin generation: if this lib was around when we picked jOOQ, I's certainly had considered it. Differences: * jOOQ is an eDSL with an optional schema-to-classes generator * you write jOOQ queries in Java (or Kotlin as we do) * there's quite a bit of type-safety added when using the generator: the schema needs to be match the queries you wri…
Yep sqlc is more akin to Kotlin's SQLDelight https://github.com/cashapp/sqldelight