honeysql VS JDBI

I recall using korma way back I and I don’t recall it being terrible but I would say https://github.com/seancorfield/honeysql has very much superseded it by this point… (but I can see how that might not be obviously clear if one is to look at superficial metrics like GitHub stars for example…)

Joins can certainly work in a data format like YAML. For an example, see Honey SQL from the Clojure community [0] (though without something to contrast strings like Clojure's keywords, you miss out on the automatic parameterization).

You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task.

Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion.

0: https://github.com/seancorfield/honeysql#big-complicated-exa...

In Clojure-land, we are also using HoneySQL [1] which has similar characteristics. You are still working within SQL semantics so it's a bit more complicated, but we are doing great complicated things with just maps, no API necessary.

[1] https://github.com/seancorfield/honeysql

using honeysql we can make structured queries as well

As someone else already pointed out, next.jdbc is good for database connectivity (for Postgres and beyond). For composing the queries themselves, I strongly recommend Honey SQL. It lets you represent queries themselves as normal Clojure data structures, just vectors and maps.

Perhaps you're looking for a way of arranging SQL as an AST represented by data structures (or objects) that can be fed to a compiler. HoneySQL[0] is one such implementation of this idea and it makes your general transformation trivial for Clojure programs. You don't need to mess around with string concatenation because you have a predictable and extensible compiler for data structures (which are themselves easily composable/transformable/storable with Clojure) that you can trust to do the right thing. If you're using some weird database or need an esoteric syntax, extending the compiler to your clause is easy to do[1].

[0] https://github.com/seancorfield/honeysql

[1] https://github.com/seancorfield/honeysql#extensibility

https://github.com/seancorfield/honeysql (write SQL without having to write SQL)

I've used it from Clojure, via HoneySQL, so no ORM, no danger of SQL injection. It was really wonderful!

https://github.com/seancorfield/honeysql

I used it to quickly iterate on the development of migration SQL scripts for a MySQL DB, which was running in production on RDS.

I might have switched to H2 DB later, because that was more compatible with MariaDB, but I could use the same Clojure code, representing the SQL queries, because HoneySQL can emit different syntaxes.

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.