I've been using this a lot lately, including in a new project at work, and it's such a joy to use
Sqlc: Compile SQL to type-safe code
61–70 of 109 posts
Re: Sqlc: Compile SQL to type-safe code
#62Earlier quoted context omitted.
Yep sqlc is more akin to Kotlin's SQLDelight https://github.com/cashapp/sqldelight
That's a really nice project indeed. We looked at it I remember, when we pciked jOOQ, but it was too new to bet the farm on back then. It progressed really nicely.
Building on top of IntelliJ's parser and 'PSI' stack as a headless engine sounds slightly mad at first but seems to provide a lot of leverage, as demonstrated by the number of dialects the team is able to support via mixins. By contrast sqlc appears to require a lot of code to support each additional dialect.
Re: Sqlc: Compile SQL to type-safe code
#63There 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 keep hearing about how powerful pg is. It would be great to see an example application that uses all it's features.
Possibly close enough: https://github.com/omnigres/omnigres
Re: Sqlc: Compile SQL to type-safe code
#64Surprised 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.
I had a look. It says it's type safe but I see strings everywhere. It seems the IDE can autocomplete the strings, but does that count as type safety nowadays? (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).
TypeScript has literal types: https://www.typescriptlang.org/docs/handbook/2/everyday-type...
Re: Sqlc: Compile SQL to type-safe code
#65Surprised 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.
I had a look. It says it's type safe but I see strings everywhere. It seems the IDE can autocomplete the strings, but does that count as type safety nowadays? (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).
Every string (literal type) passed to Kysely functions is strictly typed and the compiler will fail if something invalid is passed.
Re: Sqlc: Compile SQL to type-safe code
#66Earlier quoted context omitted.
It would be great to have some sort of sql string to type parsing as some sort of plugin to TypeScript.
Didn’t use myself, but AFAIK slonik library is doing what you’ve described: https://github.com/gajus/slonik
It doesn't seem to be doing what I meant. I mean typing compile time and most importantly while using the IDE. Without having to generate types manually or importing them from a generated file.
Re: Sqlc: Compile SQL to type-safe code
#67This is such a great approach.
Coincidentally, we just released support for this in Prisma a few weeks ago: https://www.prisma.io/blog/announcing-typedsql-make-your-raw...
Re: Sqlc: Compile SQL to type-safe code
#68Surprised 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.
I had a look. It says it's type safe but I see strings everywhere. It seems the IDE can autocomplete the strings, but does that count as type safety nowadays? (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).
those are string literals and checked by the compiler.
there is kysely-codegen which generates types based on the actual database schema.
Re: Sqlc: Compile SQL to type-safe code
#69Have been enjoying go-jet that takes a different approach: analyzes the tables in your DB and generates a set of Golang structs that lets you write 100% Golang code that looks like 99% SQL. Genius! https://github.com/go-jet/jet
JET doesn't support typesafe result mapping, or typesafe table joins, I believe. And it's not possible to do that in Go without some heavy-handed code generation. A better comparison is probably Hibernate and QueryDSL in Java.
If you use jet generated models mapping(including joins) is implicitly type safe, since sql builder and models are generated from the same database schema. This doesn't apply for custom models, but custom models are rarely needed.
Re: Sqlc: Compile SQL to type-safe code
#70I don't work with Go, but this seems like a dream. I really like the SQLx query macros in Rust. I would love for something like this
I'm also using SQLx but I don't see what this adds compared to SQLx.
We don't need to generate code and we get the same type safety from queries written in plain SQL.
If anything, I wish there was a SQLx in other languages I have to support.