Mybatis Generator worked nice for java and MySQL 15 years ago..
Sqlc: Compile SQL to type-safe code
91–100 of 109 posts
Re: Sqlc: Compile SQL to type-safe code
#92There 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 totally agree and think it's because polyglot programming still kinda sucks. Either you use a universally frustrating ORM or dataframe library or you pass your db strings that even your most integrated IDEs can't really integrate into the rest of your code.
If we figured out how to do type inference and go-to-definition and all the other nice LSP stuff across language boundaries in a good way, I'd hope the things you mention would all get a lot more widely used.
Re: Sqlc: Compile SQL to type-safe code
#93We built a whole type-checker on top of SQL at http://deepchannel.com, even for dbt projects (which are sql templated with jinja). It's a shame the company had to close a year ago.
Re: Sqlc: Compile SQL to type-safe code
#94This looks like a less ergonomic version of Rust's SQLx (https://github.com/launchbadge/sqlx) but a more robust version of TypeScript's sqlx-ts (https://jasonshin.github.io/sqlx-ts/). Sqlc seems to copy the latter's unfortunate lack of inline SQL statements. Still, seems promising.
Re: Sqlc: Compile SQL to type-safe code
#95Earlier quoted context omitted.
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.
I have probably misunderstood the documentation, the built-in sql tagged template function seems to be providing static type safety using conditional types magic. But, yeah, maybe I am too optimistic about this. Well, too bad then.
Re: Sqlc: Compile SQL to type-safe code
#96There 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 missed the ole' reliable, temp tables. I always end up using them heavily for non-trivial analytic queries since it gives you so much control over query execution.
In terms of actually using SQL more effectively, I think the ideal is just a small utility to use reflection and map a ResultSet (or equivalent) into a strongly typed object using reflection.
Even inserts can get tricky because there are so many different knobs you can tune. It's pretty rare that people just need to insert into a single table with no additional selects beforehand which means there is room to play around with preemptive locking, isolation level, etc.
Re: Sqlc: Compile SQL to type-safe code
#97Earlier quoted context omitted.
Because RDBMSes are still an unsolved problem, and new features keep coming along that are actually very useful but not easy to standardize.
And if I'm doing advanced queries, I largely sympathize. Basic group by and such, though? I get why cube and roll-up aren't always there, maybe. The rest, though? If I was demanding equivalent speed, it would be one thing. I am fine needing an integration environment for that. I only want a test environment to show queries return as expected. Is also good documentation for reporting focused queries.
If you're doing very basic things, the same exact syntax will probably work on multiple. But even then, implementation details like isolation level come into play.
Re: Sqlc: Compile SQL to type-safe code
#98Earlier quoted context omitted.
And if I'm doing advanced queries, I largely sympathize. Basic group by and such, though? I get why cube and roll-up aren't always there, maybe. The rest, though? If I was demanding equivalent speed, it would be one thing. I am fine needing an integration environment for that. I only want a test environment to show queries return as expected. Is also good documentation for reporting focused queries.
If you're doing very basic things, the same exact syntax will probably work on multiple. But even then, implementation details like isolation level come into play.
Lately, it was usually the abysmal state of aggregate functions that bit me. That and wanting to use "with" to make readable sql.
I really should just change my main complaint to be that most options should have an easy to setup and tear down local equivalent for testing.
Re: Sqlc: Compile SQL to type-safe code
#99Earlier quoted context omitted.
If you're doing very basic things, the same exact syntax will probably work on multiple. But even then, implementation details like isolation level come into play.
Lately, it was usually the abysmal state of aggregate functions that bit me. That and wanting to use "with" to make readable sql. I really should just change my main complaint to be that most options should have an easy to setup and tear down local equivalent for testing.
I feel that. Postgres has dump/restore at least, though that's less portable than a unit testing fake. And the thing I use at work lacks a dump/restore feature somehow :/
Re: Sqlc: Compile SQL to type-safe code
#100There 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 performance, for which there's tons of conflicting advice rather than an agreed-upon approach. And then there's sharding. It's hard enough already.
Personally I haven't found the need for type safety in code, or even the code-SQL boundary. The DB tables have types, as does my OpenAPI or Protobuf or whatever API spec. That's basically everything already. If something slips past my tests, it's because the tests are bad, and stronger typing wouldn't have helped.