ObjectiveSync – A thin Java object persistence layer for JDBC (2015) | Hacker News Reader

ObjectiveSync – A thin Java object persistence layer for JDBC (2015)

github.com

26 pointskimi31 comments

I never understand the argument that I shouldn't use an ORM because I "should not be afraid of SQL".

No, I don't use ORMs because I'm afraid of SQL. I actually really like SQL and I'm good at writing SQL queries. But I still use ORMs very often because they help me with programmatic composability and with avoiding boilerplate.

I mostly use SQLAlchemy ORM for CRUD applications. If I need to I can still drop down to SQLAlchemy Core or raw SQL queries, but those are rare cases. When I have to debug something I always just look at the generated SQL queries, most of the time they are actually quite readable.

Until you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a week to debug. Because your ORM has a cache and by cirumventing it you introduced a discrepance between code and database.

I do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore

When you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play.

I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!

Eh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.

I really don't see this as a major problem. Just have the ability with your compiler to load a external syntax tree for the specific database sql dialect. Then have the ability in the syntax tree to define types that map directly to a type within the language.

Easiest approach would just be to resolve the syntax tree to a constant string that is then sent to the database. I don't know why for the vast majority of programming languages they lack a lot of language features that programmer do day in day out eg... text manipulation, xml parsing, json parsing all of which are pretty straight forward and time consuming in languages without multi-line string literals.

So far, I've been happy with SQLAlchemy because of the lack of unexpected behavior. It doesn't cache by default. You can call out to stored procedures, or write raw SQL if you want to.

This all works at the beginning without doubt and when your application will stay simple and small and has a small userbase. But I've also seen more than once... when your application will get a certain size it is good to remove ORM like SQLAlchemy for real speed improvements.

In the Microsoft C#, .Net world, the solution already exists.

Dapper => https://github.com/StackExchange/Dapper

A thin layer on top of ADO.Net, blazing fast, provided for free courtesy the Stack Overflow team.

I think you missed the main issue I find with ORMs, it's near impossible to debug the SQL it's using. I really think they're an abstraction too far.

Change the verbosity of the logging statements. They'll always output what SQL is going on.

Actually, I've found it's generally quite straightforward to enable logging of the SQL executed by ORMs. What I have found difficult is trying to untangle the mess of inefficient SQL and coerce the ORM to doing what I really want it to do :/

I think that depends heavily on the ORM in question. ActiveRecord's SQL can become nightmarishly complicated but the same query in DataMapper looks alot like what might be written by hand.

ActiveRecord is way more expressive than DataMapper, IMHO, particularly if you want to make a fancy query GUI, and it's because of the additional abstractions it builds into its SQL generator.

Its not a big deal in Hibernate. SQL can be logged. You can intercept everything. And you can use sophisticated monitoring (e.g. New Relic's APM). To me, debugging with an ORM like Hibernate was never more complicated than debugging with the JDBC driver.

Also, ORM implementations often contain multiple layers of abstractions, even co-existing ones (JQL vs. HQL). Personally, I don't like HQL / JQL. But it does a good job for simple tasks. For more complex things, I can write SQL and use just the mapping features of my ORM. I rather use Hibernate to get things done, than writing all the boiler plate with plain JDBC.

It's fairly easy to do this in Entity Framework. Obviously if you have a giant query it's going to make some "optimizations" that you don't like but if you have a good understanding of your object model and how your database is architected you can usually create nice SQL.

The real problem is that the object side is less abstract than the SQL side.

Definitely agree with lots of the points in "not-so-great things" list. One fellow engineer ended up using Hibernate for more analytic queries - ended up causing so many strange issues. We discovered one of the queries was doing some kind of internal secondary query for each of the top-level rows. (So for each returning row fetched it was making another SQL query to the database). Not sure why it wasn't doing the obvious join, but I guess something broke its rules. So while I like hibernate for fetch, change, update etc.. I really think you need to be careful trusting it for joins and such.

Read about jooq https://www.jooq.org/ Thank me later.

I've used this data modeling framework in Java that's similar to GraphQL: https://github.com/perfectsense/dari. I've found it leaps and bounds more productive than most ORM's and the debug tools are top notch.

ORM's work great for CRUD. Then there is always that small collection of aggregation and reporting queries that take a few minutes to write in SQL and days to kludge together with an ORM and it's mostly-feature-complete abstraction layer over SQL (SQL is an abstraction layer).

Spring + Hibernate is a sad example of extremely lame technologies dominating a whole language ecosystem.

Spring makes it pretty trivial to use JDBC or JOOQ or a variety of non-relational data stores if that's what you prefer.

Disclosure: I work for Pivotal, we sponsor Spring development.

But absence of spring makes their usage even more convenietnt.

You prefer handrolled boilerplate to JdbcTemplate?

Laravel's Eloquent and Rails A.R. is infinitely better than raw sql.

Why does this point to a github repo?

We reverted the title from the original “Why I hate Hibernate (and ORMs in general)”, which I assume is purely editorial. Submitters: please don't do this.

All these negative issues in this readme can be addressed when ORMs like Hibernate are used correctly. And some of the points are outright BS.

Good ORMs make life much easier without compromising on quality and flexibility. Hibernate is more powerful than many developers expect. Many developers tend to see ORMs as magic and don't try to understand the tool they are using.

To comment on some of the points from the readme:

> What you get from Hibernate is not POJOs. Need for DAOs and copy, copy, copy. This is useless code and often breaks. Use generators to generate boiler plate, when possible. Write tests to... test!

If you don't want a data access layer, then don't use an ORM. If you want a layer, you can model everything in a way that does not even expose the fact that an ORM is used.

> Configuration too complex. You end up modelling everything around what works in Hibernate, not your classes (as promised) or what works in the database (that is the real constraint you are facing)

Complex problems tend to have complex solutions. But, I certainly don't find Hibernate hard to configure (these days), even when the data model is complex.

> Hibernate-aware code everywhere

Can (should) be abstracted away. Use interfaces for describing entities and builders. Describe aggregated entities as Aggregates. Model query options as typed parameters. This way, the "boiler plate" becomes the contract for data access, without leaking ANY information about the ORM or whether a relational or non-relational data source / store is used.

> Different query language without a reasonable shell - you have to write code to test out a query

There are IDEs with good ORM support, like IntelliJ IDEA. Otherwise, write a little program or tool that runs the DSL against your code base.

> Very complex and inefficient queries triggered for no apparent reason. You spend a day to control something that would have taken a few minutes in SQL

I've seen complex and inefficient queries written in plain SQL. Usually, the ORM is much better at optimizing, if your data model is sane. If you have statements executed with no reason, then that's probably due to a bad design choice in your application.

> Slow to start - big problem for testing.

ORMs start pretty fast these days. For database initialization, I prefer Liquibase or Flyway over Hibernate's built in initialization.

> Bad practice - if you hide the database, you may get something done quickly, but it's a bad idea. If yor Java code expects to have a collection of one million objects as an array, it does not matter if they are lazily loaded or not - some code somewhere might want to iterate over them, and this will kill the process. You cannot really forget that there is a database somewhere, and you should not do it.

There are streams since Java 8. I use them to stream data from queries (scrollable ResultSet -> Spliterator -> autocloseable Stream). This really helps with the memory footprint. And because I abstract my data source / data store away, the source of the stream can be literally anything. It just happens to be a relational database that is accessed through an ORM.

> Aborts on commit. For long-lived transaction, you never know WHAT made the transaction abort. And what can you do next?

Who the hell event wants long-lived transactions today?!

I always liked SimpleOrm https://berglas.org/simpleorm/index.html

It should be used more...

There's a similar PHP library called NotORM http://www.notorm.com/

ORM is the Vietnam of computer science.

Reply on news.ycombinator.com