safeql VS pggen

I want sum types.

I want a statically-typed way of constructing composable queries that follow SQL rather than reinvent a different thing. It doesn't have to be the same syntax but it has to be the same structuring.

I started writing one[0] and stopped before doing all the boilerplate code generation, having moved on from the JVM ecosystem for the time being. One thing it does is treat most things like sets so we don't end up with N+1 queries. Another trick it uses is collapsing constant expressions via an expression evaluation library[1].

[0] https://github.com/karmakaze/safeql

[1] https://github.com/karmakaze/moja

Over the years, I've written many apps and utilities for myself or others (that didn't end up get used). These are the interesting ones I remember. Many not quite complete/usable. Other than hackerer.news none of them are 'up' and running. Some have and others haven't been published as opensource.

- https://hackerer.news HN viewer (source[0]): I use daily so I can see today's top stories in reverse chronological order with mainstream topics sorted to the bottom.

- qwickly[1] keyboard layout: I use all the time as an easier to learn and more comfortable to type than Colemak/Tarmak

- safeql[2]: Java type-safe SQL expression composer that reduces constant expressions and eliminates N+1 queries loading associations by always operating on set relation or array of models.

- moja[3]: Composable computation pipelines for Java: Async, Lazy, Option, Try, Result, Multi (List), Stated, Reader, Logger, Writer.

- gitgrep.com[4] Opensource SaaS version of etsy/houndd (now called hound-search).

- statuspages.me: Status page aggregator with dynamic javascript for scraping each source using selector expressions.

- movies to watch aggregator: with links to sources to watch. It was hard then to get 3rd party deep links into streaming sites so included some torrent links. Got a DMCA phone call, so took it down. Combined thumbnails, summaries, actors(?), imdb ratings, links.

- java2cpp: Translate a moderately sized java app with test suite to c++, not 100% required final manual fixups.

- swift2java (or maybe it was java2swift, it's fuzzy now): translate Swift to Java obviously, using ANTLR4. Not 100% required final manual fixups.

- gui2log: to make an ASCII rendition of on-screen GUI widgets into an application log file when form submitted, so users couldn't complain that they saw X, but got Y.

- some basic stats/ML algorithms: k-nearest neighbour, RNN back-propagation, etc?

- Java in-memory DB: Small SQL-like memory tables with indexing/searching.

- wwwsqldesigner: This exists as opensource and I extended it to infer foreign key relationships based on naming conventions used in a MySQL schema. It was great for zooming around a large ERD.

- tracelog: combination of microservices parent/child span logging and generated high level events shown as a sequence diagram. Integrated with Loggly for full/verbose logs of selected high-level events.

- pcl2bmp downscaler: Reduce high resolution HP LaserJet (PCL5) printed to file to lower resolution bitmap pages for screen display (before retina DPI was common). It aimed to shrink same-color areas and preserve black/white transitions while reducing.

[0] https://gitlab.com/karmakaze/hackerer-news

[1] https://github.com/qwickly-org/Qwickly

[2] https://github.com/karmakaze/safeql

[3] https://github.com/karmakaze/moja

[4] https://github.com/gitgrep-com/gitgrep

I completely agree. I pretty much stopped using Spring/Boot because of it, even though it could be used without Hibernate/JPA.

I tried sql2o and later switched to jdbi and Javalin for a lightweight framework. I started making a typesafe library[0] that maps bottom-up like SQL expressions but development as stalled as I haven't been doing much side-project work to use it.

[0] https://github.com/karmakaze/safeql

Interesting choice of JDBI. I was working on an SQL-friendly ORM[0] also due to distaste with Hibernate/JPQL and chose JDBI, not because it was great in any way but it did what I needed and not much else. What influenced your choice and were there any close runner-ups?

[0] https://github.com/karmakaze/safeql

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.

[1]: https://github.com/jschaf/pggen

pggen is another fantastic library in this genre, which specifically targets postgres. It is driven by pgx. Can not recommend enough.

> 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.

[1]: https://martinfowler.com/eaaCatalog/

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.

Any reason to use sqlc over pggen ? If you use Postgres, it seems like the superior option.

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.

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.

[1]: https://github.com/jschaf/pggen

[2]: https://github.com/kyleconroy/sqlc

I created pggen a few weeks ago to create my preferred method of database interaction: I write real SQL queries and I use generated, type-safe Go interfaces to the queries. https://github.com/jschaf/pggen