How Hibernate Almost Ruined My Career(ggajos.com)
ggajos.com
How Hibernate Almost Ruined My Career
http://ggajos.com/how-hibernate-ruined-my-career/
34 comments
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).
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.
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...
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.
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.
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.
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.
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!
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.
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.
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.
"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.
Not saying the situations are that closely analogous, but a huge part of high level languages is not worrying about that issue.
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.
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.
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.
"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.
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.
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.
My favorite "hibernate is slow" story, actually nHibernate in this case, was at a company that was storing the second level cache in session variables. Half the database was being deserialized then resirialized into the session storage on every request. It also completely destroyed any consistency the second level cache would have provided, because session variables are per user.
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?!
So don't use Hibernate if you are not an Hibernate expert?!
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.
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.
No, don't use Hibernate if your solution to ignoring your tools is writing your own half-assed workarounds rather than take the time to read documentation and ask the right questions.
People do this with SQL all the time; they see queries that aren't "fast enough" and they add indexes everywhere, or they "nudge" the query planner the wrong way, or anything else than to accept that maybe their data was wrongly modeled in the first place, or maybe they need to remove indexes, or actually, you know tune the DB.
People do this with SQL all the time; they see queries that aren't "fast enough" and they add indexes everywhere, or they "nudge" the query planner the wrong way, or anything else than to accept that maybe their data was wrongly modeled in the first place, or maybe they need to remove indexes, or actually, you know tune the DB.
Your spirited defense of ORMs reminds me of JWZ's XML rant. Punchline: Now you have two problems.
How is any of this a counterargument to the article? And the hypothetical developer in it is a woman. And in their (again, fictional) scenario, they struggled with Hibernate for four years.
The developers in the article make the same mistake - using native SQL "for performance" instead of working with Hibernate.
I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.
I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.
Hi (author here). This story is purely fictional. :). As a freelancer I was in many cases forced to fix some Hibernatish chaos or work within fixed technological stack where Hibernate just cross the limits of stubbornness. I don't want to say it's bad technology, just compiled some thoughts and experience of many people (including myself) into the story. Thanks for reading :)
> 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.
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.
> 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?
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?
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
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");
If eager loading seems sub optimal then I'd guess that the have some kind of data access or repository layer on top of nhibernate. Say there are 10 places requesting customer but only 1 that needs orders, using includes would be sub optimal. Of course, it's really their architecture that's sub optimal, not hibernate.
>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.
Yes, but 99% of the documentation points to Hibernate as a replacement tool (for Sql, the begin/commit/rollback, joins, etc.)
> WTF. No concept of using transactions.
This isn't uncommon. Where I'm working now we're actually busy implementing our own transactions to solve performance issues :(
Even rarer, almost no one is aware of implicit transactions. Developers: Always use a transaction, if you aren't then you are using many more implicit transactions.
This isn't uncommon. Where I'm working now we're actually busy implementing our own transactions to solve performance issues :(
Even rarer, almost no one is aware of implicit transactions. Developers: Always use a transaction, if you aren't then you are using many more implicit transactions.
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.
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.
ORMs also increase the cost of change, thwarting code evolution / refactoring.
I'd definitely disagree there. It's a lot easier to refactor code than to refactor a multitude of sql statements.
How about when refactoring your database? How does that impact your mappings, DAOs, testing regiment?
> ORMs make porting queries to another project that needs to use the same database difficult.
Wouldn't you have written a shared library through which both projects access the same database?
I know SQL pretty well (20+ years experience), but still use ORMs with nary a reason to hand-code any SQL any more. As a small-business-focused consultant using Microsoft technologies I do realise this puts me in a different bracket than others using larger-scale datasets and so forth, however for me using an ORM makes my life easier, makes me more productive, and with a little attention to detail doesn't result in performance issues for clients.
Wouldn't you have written a shared library through which both projects access the same database?
I know SQL pretty well (20+ years experience), but still use ORMs with nary a reason to hand-code any SQL any more. As a small-business-focused consultant using Microsoft technologies I do realise this puts me in a different bracket than others using larger-scale datasets and so forth, however for me using an ORM makes my life easier, makes me more productive, and with a little attention to detail doesn't result in performance issues for clients.
"ORMs make porting queries to another project that needs to use the same database difficult."
Are you arguing that that's a bug or a feature? Because literally every system I've worked with that's gone down this road has been a maintainability disaster, with the entire database schema treated as an API...
Are you arguing that that's a bug or a feature? Because literally every system I've worked with that's gone down this road has been a maintainability disaster, with the entire database schema treated as an API...
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.
'How selecting a tool without understanding if it was the right tool to use was the wrong decision'
"this just works, nobody needs to know theorical stuff anymore"
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"
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.
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.
> 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.
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.
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.
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.
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 :)
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 :)
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.
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.
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.
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?
This article: http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... 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.
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.
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?
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?
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.
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.
>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
>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.
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
>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.
> 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:
> 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.
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)
query = base_query.filter(condition_b)
> 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.
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
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.
Shameless plug: if you're looking for a no-dependencies Java 8 JDBC wrapper, we have been using 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
> 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.
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.
> makes easy things easy and difficult things indescribably hard or impossible
I've found that nearly every abstraction does this in some form. In general, the easier the easy things are, the harder the hard things are. The trick is finding a good balance for your project.
I've found that nearly every abstraction does this in some form. In general, the easier the easy things are, the harder the hard things are. The trick is finding a good balance for your project.
"Welcome to Java …"
Maybe in giant non-tech company legacy systems, or written by Indian off shore teams.
These days with Java 8 there is almost none of that bull shit.
Maybe in giant non-tech company legacy systems, or written by Indian off shore teams.
These days with Java 8 there is almost none of that bull shit.
> 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.
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.
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.
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 ?
Anyone with having worked with both, care commenting ?
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?
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?
"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.
If they had chosen to go with plain SQL, maybe the project would be finished successfully by year two.
> Software Architect
I found the problem.
I found the problem.
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-test
No codegen, just made SQL resources a top level type safe resource you could work with.
I liked the idea a lot.
https://github.com/gosu-lang/ragnardb
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.
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.
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."
"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?
Who in their right mind would use Hibernate (or any other ORM for that matter) for reporting?
Java developers?
Why does SQLAlchemy feel so much nicer than Hibernate? Is there something equivalent in the Java world?
Im a fan of JDBI http://jdbi.org/
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.
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?
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).
This page will serve as a very useful "Who not to hire" page.
"ORM" means "snake" in Swedish, and will bite you.
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.
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.
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.
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.
I think ORMs are fine for greenfield CRUD apps done with code-first. SQL is the assembly language of the backend.
SQL is an amazing and very useful tool to work with. I will never understand why people want to abstract it away.
"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)
SQL needs marketing. Become obsolete unless you understand this durable persistence and functional, high-leverage reporting service!
I understand why they do, but I don't understand why more developers don't learn SQL. _it's freaking easy_!!! I become the defacto SQL guy at every job I work because other people don't want to touch it for some reason.
I write SQL (or SOQL...ugh, Salesforce) virtually every day on the job (I do a ton of ETL in Ruby) and use it to give valuable business intelligence.
Constantly I see other programmers jump through all sorts of technical hoops to get things done that could be done in a DB query quicker with more accuracy and less mental overhead.
Just write your own toy ORM sometime. Copy the most-common functions of ActiveRecord. It's that easy. That's all it takes.
I write SQL (or SOQL...ugh, Salesforce) virtually every day on the job (I do a ton of ETL in Ruby) and use it to give valuable business intelligence.
Constantly I see other programmers jump through all sorts of technical hoops to get things done that could be done in a DB query quicker with more accuracy and less mental overhead.
Just write your own toy ORM sometime. Copy the most-common functions of ActiveRecord. It's that easy. That's all it takes.
I use ORMs (ActiveRecord in Ruby, Sequelize in node.js) but I strongly believe that the only way to correctly use an ORM is to have a strong understanding of SQL. The ORM is useful in that it makes some things faster to write, makes my code cleaner but I will often revert back to SQL for critical operations that I need to be fast and I also know enough about how the ORM writes SQL to make sure that it doesn't do stupid queries.
TLDR: ORMs are a good tool but must never be used to avoid learning SQL. An SQL knowledge is necessary to not shoot yourself in the foot.
TLDR: ORMs are a good tool but must never be used to avoid learning SQL. An SQL knowledge is necessary to not shoot yourself in the foot.
I think it's like javascript, when you had to use one language on the server then switch to something else on the client it lead to many years of trying to abstract html and javascript into java/c#...
Maybe it would help if languages would allow for first class integration with sql like asp did for html
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.