pggen
sqlc
Our great sponsors
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pggen
-
Ask HN: ORM or Native SQL?
Cornucopia is neat. I wrote a similar library in Go [1] so I'm very interested in comparing design decisions.
The pros of the generated code per query approach:
- App code is coupled to query outputs and inputs (an API of sorts), not database tables. Therefore, you can refactor your DB without changing app code.
- Real SQL with the full breadth of DB features.
- Real type-checking with what the DB supports.
The cons:
- Type mapping is surprisingly hard to get right, especially with composite types and arrays and custom type converters. For example, a query might return multiple jsonb columns but the app code wants to parse them into different structs.
- Dynamic queries don't work with prepared statements. Prepared statements only support values, not identifiers or scalar SQL sub-queries, so the codegen layer needs a mechanism to template SQL. I haven't built this out yet but would like to.
-
What are the things with Go that have made you wish you were back in Spring/.NET/Django etc?
pggen is another fantastic library in this genre, which specifically targets postgres. It is driven by pgx. Can not recommend enough.
-
Exiting the Vietnam of Programming: Our Journey in Dropping the ORM (In Golang)
> Do you write out 120 "INSERT" statements, 120 "UPDATE" statements, 120 "DELETE" statements as raw strings
Yes. For example: https://github.com/jschaf/pggen/blob/main/example/erp/order/....
> that is also using an ORM
ORM as a term covers a wide swathe of usage. In the smallest definition, an ORM converts DB tuples to Go structs. In common usage, most folks use ORM to mean a generic query builder plus the type conversion from tuples to structs. For other usages, I prefer the Patterns of Enterprise Application Architecture terms [1] like data-mapper, active record, and table-data gateway.
Having written a non-ORM Go-Postgres tool [1] similar to sqlc, I'm a big fan of this article, especially their acknowledgment that using SQL moves the eng culture towards data-centric engineering. Some thoughts:
- Application code should not rely on database table structure (like the ActiveRecord pattern). Modeling the database as a bunch of queries is a better bet since you can change the underlying table structure but keep the same query semantics to allow for database refactoring.
- Database code and queries should be defined in SQL. I'm not a fan of defining the database in another programming language that generates DDL for you since it's another layer of abstraction that usually leaks heavily.
- One of the main drawbacks of writing queries in plain SQL is that dynamic queries are more difficult to write. I haven't found that to be too much of a problem since you can use multiple queries or push some of the dynamic parts into a SQL predicate. Some things are easier with an ORM, like dynamic ordering or dynamic group-by clauses.
[1]: https://github.com/jschaf/pggen
Similar comment from a few months ago comparing Go approaches to SQL: https://news.ycombinator.com/item?id=28463938
-
Back to basics: Writing an application using Go and PostgreSQL
You might like pggen (I’m the author) which only supports Postgres and pgx. https://github.com/jschaf/pggen
pggen occupies the same design space as sqlc but the implementations are quite different. Sqlc figures out the query types using type inference in Go which is nice because you don’t need Postgres at build time. Pggen asks Postgres what the query types are which is nice because it works with any extensions and arbitrarily complex queries.
-
How We Went All In on sqlc/pgx for Postgres + Go
Any reason to use sqlc over pggen ? If you use Postgres, it seems like the superior option.
-
We Went All in on Sqlc/Pgx for Postgres and Go
I agree whole-heartedly that writing SQL feels right. Broadly speaking, you can take the following approaches to mapping database queries to Go code:
- Write SQL queries, parse the SQL, generate Go from the queries (sqlc, pggen).
- Write SQL schema files, parse the SQL schema, generate active records based on the tables (gorm)
- Write Go structs, generate SQL schema from the structs, and use a custom query DSL (proteus).
- Write custom query language (YAML or other), generate SQL schema, queries, and Go query interface (xo).
- Skip generated code and use a non-type-safe query builder (squirrel, goqu).
I prefer writing SQL queries so that app logic doesn't depend on the the database table structure.
I started off with sqlc but ran into limitations with more complex queries. It's quite difficult to infer what a SQL query will output even with a proper parse tree. sqlc also didn't work with generated code.
I wrote pggen with the idea that you can just execute the query and have Postgres tell you what the output types and names will be. Here's the original design doc [1] that outlines the motivations. By comparison, sqlc starts from the parse tree, and has the complex task of computing the control flow graph for nullability and type outputs.
[1]: https://docs.google.com/document/d/1NvVKD6cyXvJLWUfqFYad76CW...
Disclaimer: author of pggen (https://github.com/jschaf/pggen), inspired by sqlc
-
What are your favorite packages to use?
Agree with your choices, except go-json which I never tried. pggen is fantastic. Love that library. The underlying driver, pgx, is also really well written.
-
I don't want to learn your garbage query language
You might like the approach I took with pggen[1] which was inspired by sqlc[2]. You write a SQL query in regular SQL and the tool generates a type-safe Go querier struct with a method for each query.
The primary benefit of pggen and sqlc is that you don't need a different query model; it's just SQL and the tools automate the mapping between database rows and Go structs.
sqlc
-
Show HN: Sqlbind a Python library to compose raw SQL
I came across this yesterday for golang: https://sqlc.dev which is somewhat like what you want, maybe.
Not sure it allows you to parameterize table names but the basic idea is codegen from sql queries so you are working with go code (autocompletion etc).
- API completa em Golang - Parte 7
-
ORMs are nice but they are the wrong abstraction
Agreed, but tools like https://sqlc.dev, which I mention in the article, are a good trade-off that allows you to have verified, testable, SQL in your code.
- API completa em Golang - Parte 6
-
Go ORMs Compared
sqlc is not strictly a conventional ORM. It offers a unique approach by generating Go code from SQL queries. This allows developers to write SQL, which sqlc then converts into type-safe Go code, reducing the boilerplate significantly. It ensures that your queries are syntactically correct and type-safe. sqlc is ideal for those who prefer writing SQL and are looking for an efficient way to integrate it into a Go application.
-
Type-safe Data Access in Go using Prisma and sqlc
I was browsing awesome-go for ideas on how to setup my data access layer when I stumbled on sqlc. It seemed like a great option. Code generation is a strategy often used in the Go ecosystem and making my queries safe at compile time was an idea I really liked. Knex was great, but it required of me that I test thoroughly my queries at runtime and that I sanitize my query results to ensure type safety within my application.
-
Level UP your RDBMS Productivity in GO
Now, we are going to generate the code. For this purpose, we are going to use sqlc.
-
What 3rd-party libraries do you use often/all the time?
https://github.com/sqlc-dev/sqlc — for use with //go:generate
- API completa em Golang - Parte 1
- Tenha controle sobre seu SQL com Golang e SQLC
What are some alternatives?
sqlx - general purpose extensions to golang's database/sql
GORM - The fantastic ORM library for Golang, aims to be developer friendly
SQLBoiler - Generate a Go ORM tailored to your database schema.
ent - An entity framework for Go
pgx - PostgreSQL driver and toolkit for Go
jet - Type safe SQL builder with code generation and automatic query result data mapping
PyPika - PyPika is a python SQL query builder that exposes the full richness of the SQL language using a syntax that reflects the resulting query. PyPika excels at all sorts of SQL queries but is especially useful for data analysis.
Squirrel - Fluent SQL generation for golang
xo - Command line tool to generate idiomatic Go code for SQL databases supporting PostgreSQL, MySQL, SQLite, Oracle, and Microsoft SQL Server
goqu - SQL builder and query library for golang
go - The Go programming language
migrate - Database migrations. CLI and Golang library.