Show HN: A new way of ORM in Java

I think your post summarizes it pretty well. One more addition from my side would be to emphasize that "immutability by default" has been accepted as best practice, which does not really work well with with original idea of ORMs.

> For instance, adding a join to some ACL table with conditions to exclude entities the client is not authorized to access.

This specific thing is better done with row-level security (in postgres at least). This requires that each user have a role in the db and that all queries be done in transactions that switch to the relevant role; but this seems to be a best practice anyway.

>ORM solves wrong problem

It’s the same as saying that wheel solves the wrong problem, because there are other way to move things. By definition, ORM is the mapping between ER and OO models. Working with ER models directly in object-oriented languages is suboptimal, because ER design addresses the problem of storage and OOD is more efficient in solving the problem of data processing. Hence the need in ORMs, which are mainstream now exactly because they enable the efficient transition from the storage to the processing data model and vice versa.

The problems which exist in modern ORMs are usually related to the complexity of their abstraction and imperfection of the programming language: the first problem is easy to notice in JPA with fetching strategies and caching, the second one is what author of this new ORM is trying to eliminate with the code generation - the need to use the ER namespace both in mapping declarations and in queries. JPA does not solve it well, quite often requiring developers to use native queries, because Criteria API is too abstract for many use cases and too heavy for modeling queries in the code. On the other side, JOOQ is not offering a convenient metamodel and operating on too low level.

Totally agree!

As for points 1 and 2: in languages with rather powerful type-systems, this is not solved by code generation but with mere language features. Examples are Scala or D or also more academic languages like Idris or F*. No intermediate language needed.

Unfortunately many mainstream languages such as Java or C# have to rely on code generation to solve the problem.

To be honest, Ecto is not an ORM, it's a query builder with superpowers. More so Elixir is a functional language and technically the O in ORM is missing. I love Ecto, I've never seen something as easy to use and maintain but it's not something Java folks would call an ORM.

Stop using SQL already. We now have at least 4 decades of experience with them and found out that they are a suboptimal solution to the problem.

Just use an ORM or any other kind of library that removes the boilerplate and is 100x more maintainable and productive.

See how useful it is to not explain anything.

1. at least 20 years

2. ORMs work just fine in lots of applications. There’s no real need to replace them.

3. JOOQ does not remove enough boilerplate and it’s not 100x more maintainable.

Honest question: When you ditch ORMs, who or what controls the schema? Who executes migrations?

I think JOOQ "Fluent API" is a kind of silly.

Just embed the SQL statement in a string.

In same way you would embed a snippet of HTML, XML or anything else.

(You can remove some of the boiler plate of a classic Java prepared statement using a library though ... nothing wrong in that.)

JOOQ doesn’t seem like it removes much boilerplate. It looks like it does a ton of code generation, and then on the other side you have an extremely clunky way of getting your data in a usable format.

I don’t really have a horse in this race (in Clojure there’s no need to map between results and idiomatic data structures in your domain, and you can add as much or as little schema/type checking as you want) but in previous lives doing OOP I have never lamented them 5% of problematic SQL queries to the point I’d throw away the rest that an ORM gives me. Just break out into a more powerful query language, hide it behind an interface and you still get to return meaningful objects in your domain.

Both table-centric ORMs like JPA and query-centric Query Builders like JOOQ are popular approaches to DBMS agnostic data access. ObjectiveSQL’s main differentiator compared to JPA is a JOOQ-like fluent query builder API instead of JPQL, as far as I can see after a quick scan of the project.

If your app does not have a requirement to be DBMS agnostic then DAO (Data Access Objects) frameworks like Spring JDBC or MyBATIS might meet your needs. If you don’t like using an Internal DSL and/or embedding SQL in your code, then a YeSQL framework like HugSQL might work for you.

For a strictly typed object orient language like Java, no single data access framework style has emerged as ideal. All have to address the same issues: integrating DDL/DML into source control, supporting different DBMSes, generating DAOs, and DDL migrations.

I think this discussion here is good. Whether it be an ORM or something like JOOQ it is always a tradeoff. I've found that the main pain point for me with these technologies is, that in any relatively complex project, you might want to query a similar but not identical thing in different ways. For either performance or business logic reasons. So lets say you have a POJO (in the Java world), that has a bunch of annotations on it. Once you need 3 different ways to query the same thing in different contexts, that breaks down. It also hides the database layer and structure from you, that you are in fact dealing with tables, not a hierarchy of objects, which can be misleading (especially to less experienced developers). We ourselves have gone the following route: All SQL is written as SQL (We use MyBatis for interfacing with that). And the only real features we use, are mapping and flow control constructs/loops for batch data. It is a lot more writing in that sense, but it also means that the query you write is the exact same one that gets executed. As for writing some database agnostic SQL, that can be executed on all of the big 3 (Oracle, Postgres, MySQL) - I have literally never seen anyone need that in practise. It also prevents you from optimizing to database specific features (in case of postgres, CTE is a good example).

What if things don’t go wrong?

One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement.

But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions.

Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”

Do people actually use ORM to avoid writing SQL (there are other patterns for that), or do they use it because it saves writing the boilerplate of object hydration?

The biggest deal for me is type safety (I use C#'s EntityFramework). While composing the ORM queries, I get the benefit of static verification, autocompletion, and can avoid the common boilerplate of joins. When reading code, find-references and so on work.

Isn't that a graph db?