Comment by shashurup | Hacker News Reader

Comment by shashurup | Hacker News Reader

IMHO, ORM solves wrong problem. I don't see the mapping itself as a problem - in almost any language there are data structures which can represent data we query from db. The ability to map a table record to an instance of some class looks like a good idea initially. But with time you find yourself in the situation where you need to query only a subset of fields and you end up with several implicit contexts with its own set of accessible fields each.

The real problems are:

1. Boilerpalte we get in the code which extract query results. This issue is not universal. Psycopg in Python produces a lot less boilerplate than, for instance, JDBC. This problem is a lot more visible in statically typed languages.

2. Boilerplate we get creating queries. Conditionally turning part of queries on and off produces a lot of code. This is mostly due to SQL syntax being more friendly to human rather than machine. Infix logical operators in conditions, commas etc., makes it hard to write code which generates SQL.

3. SQL is not good at reusing query parts. Views don't solve all problems.

The first problem is better to solve with code generation at compile time making it possible to perform all kinds of type check etc. Generating SQL is not that easy without introducing some kind of intermediate language which is more code friendly. I think some kind of templating could solve the problem so that it would look essntialy like SQL but with ability switch part of the query on and off. The hardest part is reuse which I don't know how to address. For instance, adding a join to some ACL table with conditions to exclude entities the client is not authorized to access.

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

Interesting, it looks like you see it in different light. Really, my point was that, first, the problem of automatic mapping doesn't need to be solved - its ok to do it manually IMO, second, I'm even unsure that OO is more efficient in data processing. This is definitely subjective, but in my experience in most cases OO didn't add up much to the clarity of my intentions.

To be honest the incentive for me to post this was mostly accumulated irritatation by the fact that a mere side effect of the mapping turned to countless attempts to model SQL in the host language. Really, IMO, all of them are worse than SQL, all of them waste your time spent learning them, with all of them sooner or later you find yourself in a position when you figure how to express the SQL you want with the DSL at hand (again, it is hard to qualify this other than wasting time).

The object-relational mapping happens everytime you fetch the data from a relational database in an object-oriented program. The moment when you try to generify your code to avoid repeating lists of columns in queries and parsing of similar result sets is the moment you create an ORM tool. All the efforts to create DSLs are coming from the idea that silver bullet exists and it’s possible to cover all use cases by a single solution. It doesn’t. Trivial ORM is enough to cover 80-90% of use cases, for the rest it doesn’t make sense to try — they are usually so unique that running plain SQL and parsing the result is the best. So I agree with you, it’s probably a waste of time to build all those DSLs when we could try to improve the simple ORM experience (Spring Data is moving in the Right direction here).

Aha, I got it now. Technically you are absolutely correct. The mapping always happens. I was just aiming at cases where original ORM intent was to provide more "smooth" OO expirience, such as having object references instead of foreign keys, 1 to 1 class to entity mapping etc.

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

I cannot imagine this as a best practice, given that you will have to synchronize two identity and access management systems - the one on the frontend and the one in Postgres. Compared to ACL or filtering of results in the service tier via something like Spring Security, it’s too much overhead for such task.

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.

Reply on news.ycombinator.com