Hacker News new | comments | show | ask | jobs | submit login

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.




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


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.


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.


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


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


> common of a problem to have to ship code that has to work with different database

when you are not writing a SaaS, but shipping a piece of software for a customer to run on their own server, it's a very common use case to support different database vendors - especially in enterprise software.


Generally the database to use is dictated by the software, that or it will support one or two, not any database.


It's useful to, for instance, run your test suite against an in-memory database like sqlite or hsql, but use a "real" database in production.


I think using VMs or something like Vagrant is a much better solution to that problem. You generally don't want to test against something that's drastically different than what you run in production.


If at all possible, you should choose one DBMS and stick with it.

There are non-abstractable differences once you no longer have a toy project, e.g. locking and isolation semantics.

There might be some valid reason for making your applications talk to different DBMS, but you have a tough slog ahead no matter how you do it.


> If at all possible, you should choose one DBMS and stick with it.

Yeah, sure, go tell that to your manager who promised multi vendor compat to your clients.

Problems with the ORM nowadays always stem from developers who are ignorant of SQL. Those people should not be working for you anyway.


> go tell that to your manager who promised multi vendor compat to your clients

Okay, I'll tell him that 5x the systems means more work, possible bugs, etc. Seems logical.

I'll tell him the same thing if he promises Windows, Mac, Linux, Solaris, and Plan 9 compatibility.

I'm not saying you shouldn't be able to use the same application with several databases; I'm saying you should avoid it.


Why don't you write your code so you don't have to choose a compiler vendor or runtime? Java today, Rust tomorrow!


Agreed.

The working approach is: Use Hibernate (or any other ORM) so that you only need to write the SQL that matters.

There is nothing wrong with using a tool to make your life easier, and there is a lot of necessary-but-borderline-boilerplate work that needs to be done when interacting with a database: validation, caching, transaction management, etc.

An ORM can handle the 90% use case for these things, freeing the programmer to focus on the 10% where the business value actually lives.

Using an advanced tool doesn't remove the need to understand what is going on under the hood: it just eliminates the need to care about the inner workings until they interfere with solving the problem-at-hand.


> An ORM can handle the 90% use case for these things, freeing the programmer to focus on the 10% where the business value actually lives.

I'd say focus on the 10% that hibernate sucks at, which will be independent of the business value.


Well, it really comes down to what you do "so you don't have to" do another thing. That's somehow something that is often ignored.

"Use Hibernate", for example, equates to "let third party software I don't understand fiddle around with my bytecode after compilation". That not only crosses the "Nope-line" for me, that even runs past the horizon behind it.

Ignoring that, if a tool like Hibernate requires you to write your business data definitions (i.e. classes) in their specific way, I'd say something's fishy. You'll never be able to untangle the two. Note that, for all their repetitiveness, that's something SQL-based DB interaction approaches would never do.

Edit: It's perhaps noteworthy to mention Uncle Bob's talk about the "Clean Architecture". I think his arguments on how to structure a Codebase based on what is actually important have much much merit to them.


So writing C "so you don't have to" write assembler is an anti-pattern?

I think the real anti-pattern that leads to ORMs is the fact that languages have no way of natively dealing relationally with data. This is the real origin of the impedance mismatch problem. Languages still deal with data using hierarchical and linear models.


Extrapolating your argument to the extreme: why write ruby when you can write C? Why write C when you can write assembly? Why write assembly when you can write binary?


For some reason people don't use the phrase " so you don't have to" when selling you on complete abstractions like higher level languages. I've only ever heard that exact phrase when someone is shilling an incomplete abstraction, which is funny because that is case when you still need to understand the lower level.

Everything in engineering is about trade offs. You bullshit detector should go off whenever someone acts like there are only pros and no cons. The phrase "so you don't have to" seems to pop up when someone is trying to pull to wool over your eyes.


Yes, higher level languages are "so you don't have to". You just declare a function with parameters, for example, and don't have to worry about which numeric offset into the stack frame is that parameter, and where do the local variables start. You don't have to worry about allocating registers to your intermediate values.

"So you don't have to" is entirely valid.

You have running water so you don't have to walk half a mile to some well with a bucket. The trade off is the whole plumbing infrastructure and the trade which maintains it.


"Use garbage collection so you don't have to call free and deal with segfaults" is an absurdly common thing for people to say.

Not saying the situations are that closely analogous, but a huge part of high level languages is not worrying about that issue.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: