safeql VS JDBI

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

While this may work for greenfield applications, I don't see this working well for preexisting schemas. From their getting started page: "Database fields are automatically created for any abstract getter methods", which definitely scares me away since they seem to be relying on automatic field type conversions.

I prefer to manage my schemas when I can and do type and DAO conversions via mapper classes in the very simple and elegant JDBI framework where you write SQL annotations above your DAO methods https://jdbi.org/#_declarative_api

JDBI does wonders for wonky old schemas you've inherited, since joins etc work out of the box (just throw them in your annotations!) The annotations can also link to .SQL files for the big hairy queries.

All these "do magic" frameworks (hibernate being one of the first) work in the simple cases but then fall apart whenever you need to do anything complex/not-prescribed. I end up having to dig into the internals of the framework to see what's going wrong which negates their whole value add.

> I've been doing ORM on Java since Hibernate was new, and it has always sucked.

Have you ever looked at something like myBatis? In particular, the XML mappers: https://mybatis.org/mybatis-3/dynamic-sql.html

Looking back, I actually quite liked it - you had conditionals and ability to build queries dynamically (including snippets, doing loops etc.), while still writing mostly SQL with a bit of XML DSL around it, which didn't suck as much as one might imagine. The only problem was that there was still writing some boilerplate, which I wasn't the biggest fan of.

Hibernate always felt like walking across a bridge that might collapse at any moment (one eager fetch away from killing the performance, or having some obscure issue related to the entity mappings), however I liked tooling that let you point towards your database and get a local set of entities mapped automatically, even though codegen also used to have some issues occasionally (e.g. date types).

That said, there's also projects like jOOQ which had a more code centric approach, although I recall it being slightly awkward to use in practice: https://www.jooq.org/ (and the autocomplete killed the performance in some IDEs because of all the possible method signatures)

More recently, when working on a Java project, I opted for JDBI3, which felt reasonably close to what you're describing, at the expense of not being able to build dynamic queries as easily, as it was with myBatis: https://jdbi.org/

That said, with the multi-line string support we have in Java now, it was rather pleasant regardless: https://blog.kronis.dev/tutorials/2-4-pidgeot-a-system-for-m...

I don't think there's a silver bullet out there, everything from lightweight ORMs, to heavy ORMs like Hibernate, or even writing pure SQL has drawbacks. You just have to make the tradeoffs that will see you being successful in your particular project.

I found JDBi[1] to be a really nice balance between ORM and raw SQL. It gives me the flexibility I need but takes care of a lot of the boilerplate. It's almost like a third category.

1. http://jdbi.org

You could use something like jdbi or mybatis. It's not as ugly as raw jdbc and easier to use without all of the gunk from an ORM like hibernate.

We use JDBI. Very simple and lightweight. It uses an object mapper not a full fledged ORM.

Alternatively there are... hybrid solutions like Kotlin's https://github.com/JetBrains/Exposed or https://jdbi.org/ that don't quite... do all the heavy lifting for querying but allow you to sorta stitch queries together manually.

As seems that Micronaut does not include anything similar by default, we use JDBI and that SQL to retrieve one random greeting from the greetings table.

Ah! E sobre o que eu usei no backend, alem de postgres e fly.io, o backend eh eh Java, usando um framework chamado quarkus e jdbi pra fazer a interface com o banco.

More personally, I'm not much an ORM guy. I've just never found that the benefits outweigh the costs, but that's just my opinion. That said, I don't use JDBC directly in my own projects anymore, strongly preferring to use JDBI instead. I find that it walks the line between "make using the database easier" and "get between you and the database" beautifully. But there's not a darn thing wrong with using JDBC directly.