
ObjectiveSync – A thin Java object persistence layer for JDBC (2015) - kimi
https://github.com/l3nz/ObjectiveSync
======
skrause
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.

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

~~~
hackits
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!

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

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

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

Dapper =>
[https://github.com/StackExchange/Dapper](https://github.com/StackExchange/Dapper)

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

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

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

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

------
ssijak
Read about jooq [https://www.jooq.org/](https://www.jooq.org/) Thank me later.

------
mmmbacn
I've used this data modeling framework in Java that's similar to GraphQL:
[https://github.com/perfectsense/dari](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.

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

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

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

~~~
avodonosov
But absence of spring makes their usage even more convenietnt.

~~~
jacques_chester
You prefer handrolled boilerplate to JdbcTemplate?

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

------
nickodell
Why does this point to a github repo?

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

------
einrealist
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?!

------
philippeback
I always liked SimpleOrm
[https://berglas.org/simpleorm/index.html](https://berglas.org/simpleorm/index.html)

It should be used more...

~~~
jack9
There's a similar PHP library called NotORM
[http://www.notorm.com/](http://www.notorm.com/)

------
oceanghost
ORM is the Vietnam of computer science.

