Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sqlc: Compile SQL to type-safe code

sqlc.dev

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Sqlc: Compile SQL to type-safe code

#101

Post by tlonny »

cies wrote: post #55
tlonny wrote: post #51

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.

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 can do some wacky stuff with strings. Not only will it give you autocomplete and prevent “bad strings”, you can write “foo as bar” in your select and typescript figures out the return type has a field “bar” by parsing the string at compile time!

Re: Sqlc: Compile SQL to type-safe code

#102

Post by nesarkvechnep »

kccqzy wrote: post #77
seer wrote: post #44

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…

You may be interested in https://docs.postgrest.org/en/v12/ an automatic way of creating a REST API from the database. It even uses the database to do authentication which is very rarely seen in production (CREATE ROLE, GRANT SELECT, etc). And you create functions in the database to customize things including implementing custom RPC methods when the standard REST is insufficient. Many devs however would consider crea…

I see nothing related to REST. No hypertext and hypermedia.

Re: Sqlc: Compile SQL to type-safe code

#103

Post by pier25 »

renhanxue wrote: post #90
pier25 wrote: post #89

Earlier quoted context omitted.

Honestly I'm not convinced about using anything else but actual SQL. I'm not an SQL expert and find it very helpful to be able to copy/paste SQL code between the app and a DB client. If Jet provided a tool to translate their API to/from SQL I might consider it though.

I may be misunderstanding you, but at least for the "to SQL" part I think that's just someJetStatement.DebugSql() All Jet-generated Statement objects have the .DebugSql() method. It returns the generated query as a string with all the bound parameters inlined[0] so you can just print it or grab it with the debugger and copypaste it into your query console. [0]: that is, it translates the query it'd actually execute,…

That's good but what about the other way around?

I mean if I start writing a complex query in a DB client and then want to translate it to Jet.

Re: Sqlc: Compile SQL to type-safe code

#104

Post by renhanxue »

pier25 wrote: post #103
renhanxue wrote: post #90

Earlier quoted context omitted.

I may be misunderstanding you, but at least for the "to SQL" part I think that's just someJetStatement.DebugSql() All Jet-generated Statement objects have the .DebugSql() method. It returns the generated query as a string with all the bound parameters inlined[0] so you can just print it or grab it with the debugger and copypaste it into your query console. [0]: that is, it translates the query it'd actually execute,…

That's good but what about the other way around? I mean if I start writing a complex query in a DB client and then want to translate it to Jet.

No automated way to do that, I'm afraid. That said, most of the Jet statement builder API maps directly to SQL keywords, so it's usually straightforward. Still, some specific things are pretty awkward (CTE's come to mind).

Re: Sqlc: Compile SQL to type-safe code

#105

Post by simplify »

1propionyl wrote: post #88
simplify wrote: post #87

Earlier quoted context omitted.

Understandably so, it's the impressive power of TypeScript's type system. No other mainstream language has arbitrary union types like this.

Arbitrary unions of literals as types have been done before dynamically (Lisps, Prologs, Erlang) and done elsewhere statically(Python). The more distinctive features in TypeScript would be what you can to with keyof/typeof, indexed access types, conditional types and especially mapped types.

TypeScript's unions are still impressive as you can union anything, not just literal types (TIL python has unions for literals, thanks).

Out of curiosity, what do you mean by dynamically? Isn't that just a case statement, or am I misunderstanding?

Re: Sqlc: Compile SQL to type-safe code

#106

Post by 1propionyl »

simplify wrote: post #105
1propionyl wrote: post #88

Earlier quoted context omitted.

Arbitrary unions of literals as types have been done before dynamically (Lisps, Prologs, Erlang) and done elsewhere statically(Python). The more distinctive features in TypeScript would be what you can to with keyof/typeof, indexed access types, conditional types and especially mapped types.

TypeScript's unions are still impressive as you can union anything, not just literal types (TIL python has unions for literals, thanks). Out of curiosity, what do you mean by dynamically? Isn't that just a case statement, or am I misunderstanding?

> TypeScript's unions are still impressive as you can union anything, not just literal types (TIL python has unions for literals, thanks).

You can do this in Python too..?

Re: Sqlc: Compile SQL to type-safe code

#107

Post by pdimitar »

paperplatter wrote: post #100
seer wrote: post #44

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…

Whenever I write a backend, it's a thin layer on top of the RDBMS like you said. I don't know if a lib or framework could help with this. It's more about designing the schema well, avoiding excessive tooling (ORMs, query builders, etc), not trying to abstract away the DB, and writing ample integration tests. If you get that stuff out of the way, you can focus on the real problems like design, xact isolation, and perf…

I have successfully used stronger typing systems (Rust in this example) to code-generate tests.

So they can be utilized to save us some work.

Re: Sqlc: Compile SQL to type-safe code

#108

Post by paperplatter »

pdimitar wrote: post #107
paperplatter wrote: post #100

Earlier quoted context omitted.

Whenever I write a backend, it's a thin layer on top of the RDBMS like you said. I don't know if a lib or framework could help with this. It's more about designing the schema well, avoiding excessive tooling (ORMs, query builders, etc), not trying to abstract away the DB, and writing ample integration tests. If you get that stuff out of the way, you can focus on the real problems like design, xact isolation, and perf…

I have successfully used stronger typing systems (Rust in this example) to code-generate tests. So they can be utilized to save us some work.

That's neat. It should be just as easy in theory to generate tests from the OpenAPI spec, but idk what tooling there is.

Re: Sqlc: Compile SQL to type-safe code

#109

Post by pdimitar »

paperplatter wrote: post #108
pdimitar wrote: post #107

Earlier quoted context omitted.

I have successfully used stronger typing systems (Rust in this example) to code-generate tests. So they can be utilized to save us some work.

That's neat. It should be just as easy in theory to generate tests from the OpenAPI spec, but idk what tooling there is.

Ah, we have `openapi-generator` already (look it up) and it works well enough. I plan on starting to use OpenAPI only for types and be able to generate structs and various other types in several languages -- fingers crossed.
Post reply on HN