
How Hibernate Almost Ruined My Career - lightlyused
http://ggajos.com/how-hibernate-ruined-my-career/
======
quantumhobbit
The idea of "use Hibernate so you don't have to write SQL" while being
objectively wrong, also hits on an antipattern I've noticed over and over
again. The "\- so you don't have to -" anti pattern. Such as "we will
configire this in xml so you don't have to write more code". Or "put some code
in the database so you don't have to do a deployment process to make changes."

You always end up having to do the thing you were trying to avoid plus deal
with the middleman abstraction you introduced trying to avoid it. Anytime I
hear someone say "\- so you don't have to -" I wince and anticipate upcoming
technical debt.

~~~
toast0
I'm not sure "so you don't have to" is the problem; it's that do X so you
don't have to do Y is only helpful if X costs less than Y.

So use an ORM so you don't have to write and maintain SQL is bad, because
writing and maintaining SQL is not expensive, but using an ORM is (at least in
my experience: I've run into many cases where the ORM generates pathological
queries that aren't fixable without throwing away all the code that was
calling into the ORM; where a bad query in plain SQL is usually readily
accessible).

On the other hand, use Erlang's hot code loading so you don't have to restart
nodes to update code is not bad: hot code loading isn't super expensive (you
have to do a little bit of planning for some types of changes), but restarting
nodes is (first you have to move all the traffic, then you have to actually
restart it, then you have to move the traffic back).

~~~
chii
my take on hibernate, or ORMs in general, is really to abstract the
_differences_ between vendors' sql implementation (including creation, and
upgrading of schema). If you have to ship a product that have to work under
all database vendors, an ORM like hibernate is the only choice - otherwise,
you'd have to write separate scripts for each vendor, and that just makes the
job at least 5x harder (or more, assuming you go for more vendors).

Not kwowing how to write proper SQL is a problem, and ORM won't solve that for
you.

~~~
guelo
Doesn't seem like that common of a problem to have to ship code that has to
work with different databases. But if I ever had to do such a thing I would
just stick with ANSI SQL.

~~~
koolba
There's no such thing as ANSI SQL for real world applications on real world
databases. Even something as simple as limiting the number of rows returned
varies widely (TOP vs LIMIT vs rownum).

The correct answer is to forget about database independence and double down on
just one[1] so you can use it to its full potential.

[1]: _And obviously it should be Postgres..._

~~~
xxs
and you missed "fetch first" which is the ANSI thing

------
lmm
Hibernate didn't ruin his career, SQL did. If he'd actually worked with
Hibernate, rather than abandoning it for SQL at the first opportunity, he
would have got a system that performed well for less effort, was database-
independent (which makes it easier to e.g. have a better test suite, because
you have a wealth of in-memory options for testing so you can afford to run
more tests on each build) and was more maintainable. All too often I've seen
it play out like this:

1\. Hibernate system working great

2\. Idiot notices that one of their queries is slow, blames Hibernate

3\. Idiot writes their query in raw SQL because hurr durr SQL is faster than
Hibernate. (Bonus points for never benchmarking anything. Extra bonus points
for switching to SQL and adding an index at the same time, observing this
makes it faster, and deciding it's probably the switch to SQL that made the
difference)

4\. Idiot notices their query is getting results that are inconsistent with
recent changes that went via Hibernate.

5\. Rather than making any effort to fix this properly, idiot disables all
caching in Hibernate. There, I fixed it.

6\. Idiot notices that Hibernate queries are now slow (gee, ya think?) and
uses this as a reason to migrate all other queries to raw SQL.

Hibernate doesn't save you from having to design a good data model, nor from
having to tune it for performance. You can't turn off your brain when using
Hibernate, you do still have to figure out which entities own which side of
their relationships, and when you get to a scale where performance becomes an
issue you do have to spend a bit of time doing performance tuning, _just as
you do when using SQL_. It does genuinely simplify a lot of things and save
you from writing a lot of boilerplate. But if you spend a week tuning your SQL
query and no time tuning your Hibernate query and use that as your benchmark,
no shit the SQL will be faster, and if your first resort whenever you hit a
slow query is going to be to bypass Hibernate rather than working with it then
yeah you probably shouldn't be using Hibernate in the first place.

~~~
therealmarv
By reading this I have the feeling it's like saying "You have to know every
technical part of your car in detail before you drive it". I'm thinking that
in a complex project you don't have time to do that... some people just want
to drive but not think about it too much. Seems Hibernate has too many
pitfalls if you are in hurry to develop something and you are not doing
performance measuring (and beeing able to tune it) in every step of
development.

So don't use Hibernate if you are not an Hibernate expert?!

~~~
lmm
For a fixed amount of effort, you'll do better with Hibernate than without.
But if you're an SQL expert and a Hibernate novice you should probably stick
to SQL, or else accept that you're going to have to take some time learning
(just as if you were to start using e.g. Cassandra you wouldn't expect to
immediately be as effective with it as you were with SQL).

And don't expect to mix SQL and Hibernate operations freely in the same code,
any more than you'd expect to freely mix e.g. encoding-aware String operations
and manipulation of the underlying bytes. It's possible to make good use of
the fact that Hibernate is implemented in SQL, CQRS-style: use Hibernate for
your "live" operations in your application, use SQL for reporting/aggregation
and ad-hoc querying, playing to both their strengths. But don't try to
interleave them, especially in the same transaction.

------
snarfy
> We’re always struggling with lazy/eager fetching problems. At one point, we
> decided to do everything eagerly, but it seems suboptimal, and besides,
> sometimes it’s not possible to access some fields because there is no
> session, or something like that. Is that normal?

WTF. No concept of the N+1 problem.

> We’re still struggling with which database engine to use for the final
> deployment. I thought Hibernate was portable, but we have some native
> queries that use some MS SQL magic, and we’d actually like to go with MySQL
> in the production

WTF. Why are you developing against MS-SQL then?

> Sometimes we spend days looking for errors. It seems like we have to analyze
> Hibernate-generated SQL because we have no idea why it’s not working as
> expected and it’s producing unexpected results.

WTF. If you don't understand your ORM you won't understand the queries it
generates.

> Can you help me understand how Hibernate cache works? I just don’t get it.
> There are some first/second level caches. What is this all about?

WTF. No concept of using transactions.

I've used ORMs longer than the term ORM existed. I've never once thought it as
a replacement for SQL. It's a supplemental tool.

~~~
JohnBooty
> WTF. No concept of the N+1 problem.

Huh? I feel like I'm missing something. Eager loading, done right, is how you
avoid the N+1 problem.

In ActiveRecord, _Customer.includes(:orders).where(customer_name: 'Fred')_
would execute, at most, two queries even if there are many Freds with many
orders.

The only real ORMs I've used are ActiveRecord and a tiny bit of
EntityFramework.

Is this kind of eager loading not common? Or did I misunderstand your remark?

~~~
snarfy
The N+1 problem is caused by lazy loading. It's when you have an entity, e.g.
Customer which has a property Orders with a foreign key relationship to
Customer. The property is not materialized until it's accessed, causing an
extra (N+1) query to be run.

This can be avoided with something like e.g. EntityFramework which is based on
the IQueryable interface and expression trees. In EF it would be

    
    
        var query = DbContext.Customers.Include( c => c.Orders).Where( c => c.customer_name == "Fred");
    

The value of query is an expression until it is iterated or converted to e.g.
.ToList(); The expression is built using the relationships defined in the
mapping which allows EF to use a proper SQL join, avoiding two queries and the
N+1 problem.

------
jpgvm
I used to think I needed to learn an ORM to be able to write maintainable
software.

However time taught me writing maintainable SQL with good migration story is
way better. ORMs make porting queries to another project that needs to use the
same database difficult. It's less obvious what is really happening and the
performance usually isn't as good as hand written SQL. Hand written SQL also
means fine grained control over prepared queries, access to vendor specific
features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc.

You could argue these should be domain of DBA but in my opinion all devs
should atleast know SQL at this level.

~~~
specialist
ORMs also increase the cost of change, thwarting code evolution / refactoring.

~~~
flukus
I'd definitely disagree there. It's a lot easier to refactor code than to
refactor a multitude of sql statements.

~~~
specialist
How about when refactoring your database? How does that impact your mappings,
DAOs, testing regiment?

------
leothekim
Straw man script about what happens when you "blindly use Hibernate." I
suppose there are lots of people in the world who do that. I would think that
Hibernate isn't the sole problem in those cases.

~~~
NeutronBoy
'How selecting a tool without understanding if it was the right tool to use
was the wrong decision'

~~~
raverbashing
"this just works, nobody needs to know theorical stuff anymore"

------
sophiedeziel
I suggest a better title for that article: "How I blame technology X of almost
ruining my career when I am the only one to blame because I did not understand
what I was doing"

~~~
quantumhobbit
I sort of sympathize though because there is overwhelming pressure to use the
latest fad in software engineering. At one point Hibernate was the cool new
thing, so cool that even non technical managers heard of it. And you really
don't want to have to explain to ever busybody non programmer why you aren't
using the cool new thing they are reading about. Even if you do explain
yourself well, there is a chance they won't understand and will just assume
you are incompetent or behind the times for not using Hibernate. Much easier
to just use the damned thing and hope for the best.

If you doubt me on this, I challenge you to go to a typical enterprise and
develop a web page with vanilla js or HTML forms today. Or build a data
project without using something like Spark, even if you only have a few
hundred MBs of data.

~~~
Daishiman
> If you doubt me on this, I challenge you to go to a typical enterprise and
> develop a web page with vanilla js or HTML forms today. Or build a data
> project without using something like Spark, even if you only have a few
> hundred MBs of data.

No, that problem is called "having shitty people skills that are so grave that
you can't sell the benefits of mature technology and experience to people who
leave and breathe cost-benefit analyses".

The only common theme is developers who can't interact with non-technical
staff.

Most people out there are actually working with relatively mature and
effective tools, it's just that the only way you notice people _not_ catching
on to fads is the dead silence of keeping your head down while solving real
problems.

------
anthonybsd
This doesn't look like it was a problem with Hibenrate, more of a "wrong tool
for the job"-scenario. Reposting what I recently wrote on Reddit on a similar
Hibernate discussion thread:

In my experience, ORMs and specifically SpringData-JPA-Hibernate occupy this
weird niche in the enterprise spectrum. They are an overkill for small
projects and they become a hinderance for large projects, so they sort of sit
there for medium projects. If you start with an ORM on a medium size project
and it becomes a big project you can sometimes find yourself in an awkward
spot where you are writing a lot of SQL (and not of the JPQL kind). With
Hibernate/JPA specifically there are so many things that are broken that they
just start getting in the way if your schemas become large enough. To me this
is really just a manifestation of Behavioral Problem (Martin Fowler,
Enterprise Patterns), where relational databases don't really map to objects
at all when you get down to it.

Basically, if you are going to do quite a bit of SQL, any ORM will just in the
way. Should be plainly obvious to anyone with experience.

~~~
sametmax
It depends a lot of the ORM. SQLAlchemy allows you to ditch the ORM when you
need it. But instead of going back to raw sql, you just get a DSL like LINK,
which is very flexible and can express most of the stuff you could do with
manual SQL, while still retaining many benefits of using a wrapper.

It's my understanding that Hibernate doesn't allow this.

> Basically, if you are going to do quite a bit of SQL, any ORM will just in
> the way. Should be plainly obvious to anyone with experience.

This is the problem you see : a lot of project don't have somebody very
experienced with SQL anymore. Because they need to know a bit of sysadmin, and
front en dev, and deployment, and CI, etc. So an ORM helps a lot in that
regard, and will help most projects because the problems it causes are smaller
that the ones it solves:

\- it forces people to put the schema, migrations and validation code in a
centralized place.

\- it let you reuse your API knowledge instead of having to relearn the stuff
for SQLite/Postgres/MySQL/Access.

\- it enforces good practices on security with data escaping and cleaning.

\- it let you benefit from your language tooling (analytics, linters,
completions, doc, shells) to write queries that otherwise would be plain text
in the middle of the file for most people.

\- it gives a structure to DB operations, so if you look for something, you
know where and what to look for.

\- it gives you an event system to decouple queries and their effect.

\- it gives a common API so you can write easily libs targetting the ORM. This
is why the django ecosystem is so rich : you can write an auth backend or a
tagging system and know other people will be able to just plug it in.

\- it comes with tooling: auto generated admin, forms and APIs, migration
manager, paginators...

It does have a cost in perf and sometime flexibility. But for anything that
doesn't have 1 million of users yet, it's worth it. Especially in a world
where a daily salary can be more than a year of server time.

I cache everything anyway :)

~~~
aidos
And it allows you to write specific queries that can then be post filtered /
ordered / paginated by a more general mechanism.

Or you can write queries and play around with loading strategies later /
change them over time as the shape of the data changes without having to
change any other code.

Every time the ORM thing comes up on HN most people jump on the ORMs are evil
bandwagon. I think sqlalchemy is probably a bit of an exception in terms of
just how flexible it is, however in my experience you get all the benefits
with next to no downside (performance overhead being the most obvious). I
generally wouldn't start a project without it these days.

------
azinman2
I don't understand why SQL is avoided so much. Yes it can be a pain to
get/transform types depending on the driver/adapter, but to me that's the
whole of a thin wrapper. SQL is just code, not another API to learn, is
typically just as self explanatory if not more, let's you use vendor-specific
features easily, removes any voodoo so it's clearer what's going on, and isn't
that hard to begin with.

------
ransom1538
Look, if you write clear sql anyone will be able to read it. ANSI sql can be
read by people even from other languages. You need to wrap it layers of
bizarre abstraction and tape on language specific orms. How else will you keep
your job?

------
lucio
This article: [http://blogs.tedneward.com/post/the-vietnam-of-computer-
scie...](http://blogs.tedneward.com/post/the-vietnam-of-computer-science/) is
10 yrs old. It is clear and to the point. ORM is a bad choice. Take a little
time to Learn SQL basics, it is easier than any programming language.

------
pstuart
I supported a deals site that used Hibernate with JBoss. We went through
several years of scaling pain until a consulting engineer found that the
Hibernate cache settings were left at their defaults.

------
aisofteng
Frankly, I've never understood the real-world utility of ORMs such as
Hibernate. As far as I can tell, their purpose is to "abstract away" a
database. But why?

SQL isn't hard. Learning database optimization is nontrivial but doable for
anyone. Why do we need ORMs? Why is it better to replace a "WHERE ..." clause
with ".where(...)"?

My personal impression is that these frameworks were developed for people that
know how to write code in some language but don't know how databases work and
want something easy instead of learning how databases work. It really feels
very lazy to me.

If you have a library or framework thatproperly prevents SQL injection
attacks, why use an ORM unless you feel too lazy or scared to learn how to use
a database properly?

~~~
Daishiman
SQL cannot be trivially composed. If you want to dynamically build a query
you're better off using a query builder to generate that SQL than trying to
play around with strings.

SQL lacks support for some pretty basic things like query aliases. Try writing
5 nested queries vs using variables to store the different criteria.

SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY
should be irrevant. Join syntax is frankly horrendous. It's difficult to
autocomplete.

Embedding SQL in your code is a recipe for disaster. Your compiler does not
understand it, therefore refactoring means going over every query you have and
manually looking to see what changes to do. It cannot be validated in compile
time. SQL strings have no knowledge of the backing domain until they're
actually run.

And finally, 99% of the time you _really do_ want to fetch and object with
relations from the DB, not simple maps of field names. Aliasing field names in
SQL from joins is a waste of my time. Making the returned data map to whatever
object actually contains the business logic I'm interested in gets old, fast.

~~~
aisofteng
>SQL cannot be trivially composed. If you want to dynamically build a query
you're better off using a query builder to generate that SQL than trying to
play around with strings.

SQL isn't supposed to be composed. It is a query language for a relational
database structure. What composition is to run of the mill programming
languages is what relations are to databases, roughly speaking.

>SQL lacks support for some pretty basic things like query aliases. Try
writing 5 nested queries vs using variables to store the different criteria.

"Basic things" that are basic things for programming languages. SQL has
support for what it should have support for - having intermediary variables
(in the sense that general purpose programming languages have variables) is
not one of those things. This comment belies a lack of understanding of how
databases work and why.

>SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY
should be irrevant. Join syntax is frankly horrendous. It's difficult to
autocomplete.

The decision regarding where to order is absolutely relevant and is strongly
dependent on your data model. Join syntax is a syntax to accomplish joins,
which are fundamental to modeling of relational data.

And, frankly, if autocomplete is a criteria for you, then, in the context of
these tools, you are not a developer, you are an end user.

>Embedding SQL in your code is a recipe for disaster. Your compiler does not
understand it, therefore refactoring means going over every query you have and
manually looking to see what changes to do. It cannot be validated in compile
time. SQL strings have no knowledge of the backing domain until they're
actually run.

This statement makes it clear that you have not seriously developed an
application that is strongly dependent on a serious database. At least almost
everything you said here is "not even wrong":
[https://en.wikipedia.org/wiki/Not_even_wrong](https://en.wikipedia.org/wiki/Not_even_wrong)

>And finally, 99% of the time you really do want to fetch and object with
relations from the DB, not simple maps of field names. Aliasing field names in
SQL from joins is a waste of my time. Making the returned data map to whatever
object actually contains the business logic I'm interested in gets old, fast.

I suggest you take a look at database design and relational information
modeling. You really seem to not know what the problems are that relational
databases solve, how to use them, or how to use them well.

~~~
Daishiman
> SQL isn't supposed to be composed.

How do you build a filtered search system? Query languages can _definitely_ be
composed. Look at Codd's relational algebra operators; they can most
definitely be composed.

You _can 't_ do this in SQL:

base_query = get_base_query()

if condition:

    
    
        query = base_query.filter(condition_a)
    

else:

    
    
        query = base_query.filter(condition_b)
    

This idiom happens _all the time_ in code with dynamic queries. It's handled
trivially by any decent ORM. There's absolutely no excuse since you can do the
same thing in relational algebra.

> SQL has support for what it should have support for - having intermediary
> variables (in the sense that general purpose programming languages have
> variables) is not one of those things. This comment belies a lack of
> understanding of how databases work and why.

Um, no. In fact the WITH statement was added in the latest SQL standard to
help with this because, well... it turns out writing 5 nested queries _is_ a
pain.

> And, frankly, if autocomplete is a criteria for you, then, in the context of
> these tools, you are not a developer, you are an end user.

And you've never heard of data analysts who literally spend all day doing
nothing but running queries and reports? You've never run drafts of queries to
see if you're doing reasonable things?

> I suggest you take a look at database design and relational information
> modeling. You really seem to not know what the problems are that relational
> databases solve, how to use them, or how to use them well.

If you're going to lecture someone when you have no proof of backing your
assertions with real-life use cases then I suggest you actually go read Codd's
original paper on relational algebra rather than praising SQL as something
handed down from the gods. It's an imperfect representation of the tree
structure of relational queries composed of projections, joins, and
selections.

If you're going to be cargo culting SQL, at least actually understand what the
original was. SQL was the 70's idea of a "natural-looking" language to model
relational algebra. And relational algebra is only one way to understand
relational data stores (tuple calculus is another decent formalism for
understanding it as well). And relational stores are only one of many
different data modeling tools.

There is literally _nothing_ in SQL that you cannot do more ergonomically with
most query builders, since everything boils down to the same thing: an
abstract tree of query expressions that can be understood by a DB engine and
manipulated through basic relational algebra rules to optimize according to
heuristics.

------
725686
If you need to map relational database to objects and don't use an ORM, you
will eventually reinvent it, in a bad ugly and buggy way. ORM is hard.
Hibernate is a fantastic robust thoroughly tested and massively successful
framework. But as any power tool, in the wrong hands can be a disaster.

[https://martinfowler.com/bliki/OrmHate.html](https://martinfowler.com/bliki/OrmHate.html)

------
mnm1
For our API, I've rewritten probably 2/3 of the public endpoints to use raw
SQL. I'd like to rewrite the other apps as well. The non-ORM app has no issues
whatsoever. I estimate probably an eighth to a quarter of the time I've spent
in the last three years has been dealing with completely avoidable ORM issues.
Yeah, I can relate. At least it wasn't my choice to use them. It's a minor
consolation.

------
revetkn
Shameless plug: if you're looking for a no-dependencies Java 8 JDBC wrapper,
we have been using
[https://github.com/pyranid/pyranid](https://github.com/pyranid/pyranid) in
production for a number of public-facing projects over a couple years and it
has worked very well for us

------
wtbob
> I had to learn Hibernate architecture, configuration, logging, naming
> strategies, tuplizers, entity name resolvers, enhanced identifier
> generators, identifier generator optimization, union-subclasses, XDoclet
> markup, bidirectional associations with indexed collections, ternary
> associations, idbag, mixing implicit polymorphism with other inheritance
> mappings, replicating object between two different datastores, detached
> objects and automatic versioning, connection release modes, stateless
> session interface, taxonomy of collection persistence, cache levels, lazy or
> eager fetching and many, many more.

Welcome to Java …

I generally find that an ORM makes easy things easy and difficult things
indescribably hard or impossible. Honestly, the relational model is great, and
it's worth understanding well. Frankly, if you're a software developer and you
can't learn SQL … you're not really a software developer.

~~~
flukus
> I generally find that an ORM makes easy things easy and difficult things
> indescribably hard or impossible.

I agree, but raw sql makes the easy thing hard (or at least cumbersome), so
the nice middle ground is to use hibernate for the easy things and sql for the
hard things.

~~~
wtbob
With respect, I just don't find SQL that difficult, _especially_ for the
simple things that an ORM does a nice job with. "select foo, bar, baz from
quux where uuid = '8bd67f1e-6bb8-4ccb-8ad4-fa631b36ab8e'" is _easy_.

------
gime_tree_fiddy
Maybe this is out of inexperience, but having worked with Rails' and Django's
respective ORMs, some of the things, about Hibernate, from this article like,
lacking migration support seem a bit strange. And never having used it, feel
like I am not seeing the complete picture.

Anyone with having worked with both, care commenting ?

------
yomly
In this story, Monica was able to actually get to year 4. What's to say that
if she went with raw SQL, the team never would have been productive enough to
match their run rate. For every story there is of a successful team who rues
using an ORM, how many teams are out there who are lost to the obscurity of
failure thanks to not choosing a fast over correct solution.

Now, this is not a judgment for or against SQL, given there are plenty of
users of Hibernate, it has clearly worked for some teams. Equally, given
people _still_ write SQL, I am sure it has worked for many people.

Fundamentally there are two questions to my post:

1 - how much could have been saved in this scenario by a better team

2 - how often is it that the right solution now becomes the wrong solution
later?

~~~
lucio
"raw sql"? SQL is not assembler. SQL is a descriptive lang a few steps higher
in the abstraction ladder from any algol-derived lang as C,java,etc.

If they had chosen to go with plain SQL, maybe the project would be finished
successfully by year two.

------
gpawl
> Software Architect

I found the problem.

------
carsongross
A long time ago, in a programming language now forgotten (gosu) some interns
and I created a SQL typeloader that allowed you to define your domain in SQL
DDL files and then write query files in SQL that were accessible, type safe,
directly from Gosu:

[https://github.com/gosu-lang/ragnardb](https://github.com/gosu-lang/ragnardb)

[https://github.com/gosu-lang/ragnardb-test](https://github.com/gosu-
lang/ragnardb-test)

No codegen, just made SQL resources a top level type safe resource you could
work with.

I liked the idea a lot.

------
bullen
Having built my own ORM and my own distributed key/value JSON store with index
over HTTP I can say SQL is the problem, SQL databases are older than the
internet, they have not evolved since the 70s. You need async on the network
preferably over HTTP (to be client agnostic) and almost no database provides
that today. Heck no programming language provides multi threaded non blocking
IO with shared memory, only C++ (and maybe modern attempts Rust, Go, Swift
etc.) and Java (C#) are capable languages.

------
Terr_
A major red flag is if you hear any developers saying things like: "The ORM
will abstract access to the database so that it's like everything's in
memory."

------
ThomaszKrueger
"To get a report, we have to wait two days!"

Who in their right mind would use Hibernate (or any other ORM for that matter)
for reporting?

~~~
koolba
I think JIRA uses it. I vaguely remember the query format for it being a form
of JPQL.

~~~
busterarm
Funny that. The larger our (not particularly large) JIRA account gets, the
slower it performs. Very noticeably so.

------
jtchang
Why does SQLAlchemy feel so much nicer than Hibernate? Is there something
equivalent in the Java world?

~~~
RhodesianHunter
Im a fan of JDBI [http://jdbi.org/](http://jdbi.org/)

------
jondubois
I knew that ORMs where a bad idea since the first time I saw one many years
ago. It never made any sense to me. I don't see how they simplify anything;
even in the early stages. SQL is actually a really simple abstraction for
fetching relational data.

------
therealmarv
Currently dealing with a simple user database in a backend, Play Framework
(Java) for a website. After reading this I'm worried doing this with EBean ORM
is not good. Any advice/comments from experts?

~~~
flukus
Do you know sql/databases well? If not learn that because you'll have to
anyway. Then learn how your ORM works and what problems it solves (and what it
doesn't).

------
lowbloodsugar
This page will serve as a very useful "Who not to hire" page.

------
jwatte
"ORM" means "snake" in Swedish, and will bite you.

------
gentleteblor
Does Java not have a good Micro ORMs (like Dapper, NPoco on the .Net side)?
They can be a wonderful middle ground between completely custom sql and a full
blown giant like Hibernate.

------
huula
I'm using scala Slick for huula, should I have this concern too since the
development there seems really like just a one company effort.

------
hibikir
Java circa 2005 had a whole lot of problems, but if you ask me, the biggest
problem of it all was that many of the 'solutions' to the problems were worse
than the disease.

Back in the day, a friend of mine brought me in to write business software in
Java for a small retail company. They didn't have much money, but they also
didn't have any management that cared about our technical decisions, so we had
a freedom that helped our careers tremendously: Nobody is making any less than
3x what they did then. But along with that freedom came the responsibility of
getting the decisions right.

Hibernate was a great improvement over the awfulness that was naked JDBC, but
the risks to bad performance were so terrible that we ended up just writing
some decorators to make JDBC usable instead. Years later, I went to a big
enterprise place, and saw what happens when developers stop learning SQL, and
use hibernate to run complex queries.... and then I learned how big of a
bullet we dodged.

Hibernate wasn't the only bullet though: One that Java is still suffering from
is Spring. We decided that exchanging boilerplate you compile for XML was not
a good tradeoff. Later they added annotations, but still, handing all of that
wiring to the runtime is just not a good idea. Spring also taught people that
it's easy to just have objects that can be constructed in ways that are broken
(zero param constructors were easier to use), made application startup slower
than even EJB, produce error messages that make the Clojure compiler seem
friendly, and added all kinds of insane nonsense that made Rod Johnson quite
rich, but didn't help Java itself move forward. Java 1.4 and java 5, out of
the box, are like a person with a broken femur. Instead of fixing the bone,
most of the ecosystem was just feeding the patient oxycodone: The result was
that the patient still had a broken bone that was setting incorrectly, and the
patient was now addicted to opiates. And yet, the people that wrote the bad
tools that caused this have nice houses in Nob Hill and get to try to build
new startups, now selling us their magical solution to the microservice
problem.

The Java ecosystem only started to move forward when Ruby on Rails came to
town, and, despite all of it's own problems, made it clear that the whole
thing had to move forward. Now the JVM has far better languages than Java, and
Java itself has actually improved in important ways, but that was due to
competition, not bad solutions to problems.

I think we are back in the same boat with NoSQL databases: The companies
selling tooling that did well didn't do so on good engineering, while the
companies that did the best engineering struggle. But is the whole movement a
good idea, or are we just going to see something like Spanner come in and the
technologies that people got so excited about were just low quality solutions
to problems that most of the time we didn't even have?

I think there's more to learn from the pattern of how developer tools succeed
(and fail to deliver), than from just the lesson of Hibernate's tremendous
shortcomings for anything complicated.

------
intrasight
I think ORMs are fine for greenfield CRUD apps done with code-first. SQL is
the assembly language of the backend.

------
xyzzy4
SQL is an amazing and very useful tool to work with. I will never understand
why people want to abstract it away.

~~~
lostcolony
"SQL seems hard" "Here's a tool that makes it so you don't have to use SQL"
"Great! Let's use that" \- without having done the work to determine if that
tool is actually any simpler (hint: it's not)

