Hacker News Reader

Comment by geoka9 | Hacker News Reader

Have 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

View on HN

Sqlboiler takes a similar approach https://github.com/volatiletech/sqlboiler

There’s nothing unique about go-jet. Jooq does the same thing for example.

Jooq is amazing.

+1 for go-jet. I came from python and sqlalchemy, where I used the declarative form to generate dynamic SQL (vs using the ORM, since I am fine with SQL) and go-jet allows me to do something similar in Go.

I wish go-jet would also start supporting duckdb, since I am exploring more local-first DB apps using sqlite, with duckdb as the query engine.

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.

Interesting. What happens if your schema is rolled back (e.g., to remove a new column), but your binary isn’t? Or is the idea to always deploy schema rollbacks alongside your binary?

Edit: Also, curious about how this would work with a progressive schema rollout across environments - e.g., staging vs. prod DB. Do you need to “wait” for your new column to hit prod before you can use it in unit tests?

Or just don't do schema rollbacks.

We allow customers to run old versions if our program against an upgraded database, and to do that we just don't do destructive schema changes.

I suppose that’s one option. But sometimes you want the ability to rollback on bad or potentially destructive schema changes.

At a basic level - database migrations must be backwards compatible at least with the previous version, and they go out before the service update is deployed.

Unit tests don't run direct against prod usually, but regardless they would be run after migrations to a database of (production schema+migrations). Each environment - dev, test, staging, prod has its own db. Even spinning up an ephemeral db per test is possible, and easy with containers.

YMMV as system complexity increases, but by then there should be whole team(s) managing the issue

SQLC has the same functionality, it does two things:

- Create structs for your custom queries - Create structs for your DB tables if you point it at a DB

Jet was built for joins though- sqlc doesn’t seem able to do those.

It can do joins. By default it combines the query into a single flatten struct but you have the option to write the query to embed entities in the join.

Not perfect and doesn't maintain the same type if you want a subset of columns but works for the majority of cases.

What about one to many joins?

Oh, so it's jOOQ but for Go. Nice. Sadly it does not support most custom Postgres things.

XO doesn’t have them built-in, but it uses easily customizable templates.

I added support for a bunch of postgres fancy stuff in a previous app, it wasn’t too difficult

https://github.com/xo/xo

I think the next release is gonna give you a lot of flexibility to write your own helpers that can generate the raw fragments you need. Not as good as having the features built in of course, but it'll do in a pinch.

jOOQ and jOOQ-like API's in other languages are the Right Thing in most cases, IMO. I've worked with very abstract ORM's, I've worked with raw SQL, and I've worked with a lot of things somewhere in between and that's my conclusion.

Supports COPY and pipelining, and all custom data types. I very rarely need to drop out of sqlc-generated code. What else could you want?

Reply on news.ycombinator.com