4 ms·

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. If I need to write a complex query, I can easily write a @Query annotation in HQL and it neatly fits right in to the repository class. I also develop with query logging enabled so I have better understanding of the queries actually ran on the DB. I think it really boils down to using the right tools, the right way.

mavelikara 7y ago
Same here. Hibernate team had always, even as early as 2003 when I first started using it, advocated for turning on show_sql=true in development. If the code interacting with the DB fetches a table - rows and columns - of data, say for displaying a report, ORM does not buy you much. Instead, if the code converts the ResultSet to entities in an OO language you always end up using an ORM - a hand-rolled one, or an off-the-shelf one. I just don't understand the hate.
mindcrime 7y ago
This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. Same. Hibernate with Spring Data JPA, for me, "just works". But it's not necessarily the right solution for every database interaction. But for a typical microservice which might have up to 20-25 discrete entities, and few if any crazy complex relationships, I find that I plug it in, extend CrudRepository, write some JPQL queries in @Query annotations here and there, and bob's yer uncle. If you were writing a monolithic CRM system with 900 domain entities, super complex rules governing the inter-relations between them, and trying to write your analytics queries right into the app, then an ORM approach would probably fail miserably.
olafure 7y ago
I have to congratulate you for having worked with a quite sophisticated and complex piece of technology for several years and never run into any issues.
qes 7y ago
> I’m shocked at how many people have issues with ORMs Simple inexperience. I'd bet most of those people are mid-level developers who have used ORMs enough to hit the rough edges but not enough, or with enough independent agency, to have worked through how to play to ORM's strengths while avoiding their weaknesses. People that were given a hammer and are just understanding that their hammer doesn't work very well to install bolts, and maybe don't have the authority to say maybe I should use a wrench or the flexibility to try this new crescent shaped idea and see if that works better.
- hombre_fatal 7y ago
  It's condescending and convenient for you to discount the people who disagree with you as merely inexperienced. You could level the same empty claim at people who like ORMs: I loved ORMs when I was a beginner but learned it's best to avoid them as I accumulated experience. So anyone who likes ORMs is merely in that beginner stage.
- tigershark 7y ago
  Or maybe you worked only on “toy” projects and never understood that you are doing more work that could be expressed more elegantly in a functional SQL expression instead of using the imperative statements of the ORM engine? The craziest thing in this discussion is that I have to defend SQL that is probably my least favourite language... I never expected this honestly.
  - Daishiman 7y ago
    My "toy" project with several hundred tables and tens of thousands of users does fine. I have, at most, a couple dozen "complex" queries in this project. Whereas I have an order of magnitude more queries that need to be composed from several different query criteria, a task for which SQL is very poorly optimized for and most ORMs excel at. I have used my ORM for so long that writing a report in SQL or the ORM language is basically the same to me. Neither technology is something I would consider to be "hard", as most of the problems encountered in practice are well-trodden. Nontheless, a simple ORM query is 20% the length of an equivalent SQL query. And I can compose them trivially. And then I use the model code for the _hard_ part: dealing with the rest of the business logic for template rendering, email sending, API interactions, and so on, for which SQL is completely useless.
lubujackson 7y ago
I'm trying to pick up FeathersJS right now and I will tell you it is hard to find ANY examples of complex queries translated to the ORM's logic. I can find bits and pieces but without any sense of the underlying purpose. There are 500 tutorials of installing Feathers and making a CRUD app, but something as simple as combining results from two requests or doing a raw DB request seems to exist only deep in the docs (and more often than not, requires bonus functionality from an add-on). I am familiar with managing databases and I can see benefits of ORMs, but I feel like "glue" technologies could benefit from deeper real-world examples that move beyond day 1 tutorials and get into translating existing code to their style. Half the time I am left digging through outdated github code to grasp the basics of how and where mid-level functionality can be used.
corebit 7y ago
You're not doing anything with it then. JPA is a relic that slows down productivity. Give me JDBI any day and I can get things done 10x faster.
Traubenfuchs 7y ago
And if you either lack the skills to properly use JPA/Hibernate or really have super custom special requirements, you can at any time execute native queries with the EntityManager. Still not enough? You can even directly work with Connection objects.

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. If I need to write a complex query, I can easily write a @Query annotation in HQL and it neatly fits right in to the repository class. I also develop with query logging enabled so I have better understanding of the queries actually ran on the DB. I think it really boils down to using the right tools, the right way.

mavelikara 7y ago

Same here. Hibernate team had always, even as early as 2003 when I first started using it, advocated for turning on show_sql=true in development. If the code interacting with the DB fetches a table - rows and columns - of data, say for displaying a report, ORM does not buy you much. Instead, if the code converts the ResultSet to entities in an OO language you always end up using an ORM - a hand-rolled one, or an off-the-shelf one. I just don't understand the hate.

mindcrime 7y ago

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. Same. Hibernate with Spring Data JPA, for me, "just works". But it's not necessarily the right solution for every database interaction. But for a typical microservice which might have up to 20-25 discrete entities, and few if any crazy complex relationships, I find that I plug it in, extend CrudRepository, write some JPQL queries in @Query annotations here and there, and bob's yer uncle. If you were writing a monolithic CRM system with 900 domain entities, super complex rules governing the inter-relations between them, and trying to write your analytics queries right into the app, then an ORM approach would probably fail miserably.

olafure 7y ago

I have to congratulate you for having worked with a quite sophisticated and complex piece of technology for several years and never run into any issues.

qes 7y ago

> I’m shocked at how many people have issues with ORMs Simple inexperience. I'd bet most of those people are mid-level developers who have used ORMs enough to hit the rough edges but not enough, or with enough independent agency, to have worked through how to play to ORM's strengths while avoiding their weaknesses. People that were given a hammer and are just understanding that their hammer doesn't work very well to install bolts, and maybe don't have the authority to say maybe I should use a wrench or the flexibility to try this new crescent shaped idea and see if that works better.

hombre_fatal 7y ago
It's condescending and convenient for you to discount the people who disagree with you as merely inexperienced. You could level the same empty claim at people who like ORMs: I loved ORMs when I was a beginner but learned it's best to avoid them as I accumulated experience. So anyone who likes ORMs is merely in that beginner stage.
tigershark 7y ago
Or maybe you worked only on “toy” projects and never understood that you are doing more work that could be expressed more elegantly in a functional SQL expression instead of using the imperative statements of the ORM engine? The craziest thing in this discussion is that I have to defend SQL that is probably my least favourite language... I never expected this honestly.
- Daishiman 7y ago
  My "toy" project with several hundred tables and tens of thousands of users does fine. I have, at most, a couple dozen "complex" queries in this project. Whereas I have an order of magnitude more queries that need to be composed from several different query criteria, a task for which SQL is very poorly optimized for and most ORMs excel at. I have used my ORM for so long that writing a report in SQL or the ORM language is basically the same to me. Neither technology is something I would consider to be "hard", as most of the problems encountered in practice are well-trodden. Nontheless, a simple ORM query is 20% the length of an equivalent SQL query. And I can compose them trivially. And then I use the model code for the _hard_ part: dealing with the rest of the business logic for template rendering, email sending, API interactions, and so on, for which SQL is completely useless.

lubujackson 7y ago

I'm trying to pick up FeathersJS right now and I will tell you it is hard to find ANY examples of complex queries translated to the ORM's logic. I can find bits and pieces but without any sense of the underlying purpose. There are 500 tutorials of installing Feathers and making a CRUD app, but something as simple as combining results from two requests or doing a raw DB request seems to exist only deep in the docs (and more often than not, requires bonus functionality from an add-on). I am familiar with managing databases and I can see benefits of ORMs, but I feel like "glue" technologies could benefit from deeper real-world examples that move beyond day 1 tutorials and get into translating existing code to their style. Half the time I am left digging through outdated github code to grasp the basics of how and where mid-level functionality can be used.

corebit 7y ago

You're not doing anything with it then. JPA is a relic that slows down productivity. Give me JDBI any day and I can get things done 10x faster.

Traubenfuchs 7y ago

And if you either lack the skills to properly use JPA/Hibernate or really have super custom special requirements, you can at any time execute native queries with the EntityManager. Still not enough? You can even directly work with Connection objects.