4 ms·

Very interesting; as someone's who been very happily using Ibatis with Java and Spring for many years I've always been wary of Hibernate for just the reasons yo

Very interesting; as someone's who been very happily using Ibatis with Java and Spring for many years I've always been wary of Hibernate for just the reasons you mention. The thought of ceding control over SQL to a framework so extensively would give me sleepless nights, and my hunch has always been that there will be a bunch of non-performant parent/child relation anti-patterns basically baked in and waiting to pounce (if that's not too much of a mixed metaphor...!).

nobullet 13y ago
I understand why people don't like ORMs. But I don't understand people who like iBatis: it is boilerplate like the hell. Imaging you have to separately update mappings for SQL select, insert, update and delete query (and these mappings are very long) for your entities. For example, prepared statement for update looks like this: PreparedStatement ps = ...; ps.setLong(1, author.getUserId()); ps.setLong(2, author.getStreamId()); ps.setString(3, author.getNetwork()); ps.setString(4, author.getIdInNetwork()); ps.setString(5, author.getNote()); ps.setString(6, author.getSocialId()); .... And manually counting questions is a normal practice when you add a field: static final String UPDATE = "UPDATE Table1 SET Domains = ?, TemplateId = ?, InternalJson = ? WHERE StreamID = ?"; static final String INSERT = "INSERT INTO Config1 (UserID, StreamID, Domains, TemplateId, InternalJson) VALUES (?, ?, ?, ?, ?)";
- fusiongyro 13y ago
  You have to pick your battles. It's convenient that Hibernate will do these things for you, but I have seen lots of times when the order Hibernate wants to remove something causes an integrity violation. For instance, a not-null foreign key reference in a linking table; sometimes Hibernate seems to try setting the value to null before deleting the referenced entity, leading to an integrity violation. There have been times when I couldn't figure out how to make Hibernate do this the right way (reversing the order of its deletes and skipping the unnecessary set-null step) so I instead just lifted the constraint. I hate when I have to do that, because ideally Hibernate should just live with whatever schema I have given it. Another example is trying to depend on CASCADE in the database. The settings you need to make to get Hibernate to accept this are quite arcane and force you to manually worry about list indexes in the Java code. Yet another example of a place where Hibernate, which ought not be telling me how to make my database or my Java code, instead winds up forcing me to take certain decisions in both.
- brianmcc 13y ago
  I can see your point, pretty valid. I guess I prefer control over magic. I can produce a complex SQL SELECT, use functions/joins/views, and populate either full entities with it or just teeny tiny DTOs, e.g. if I just need customer name and account number I can easily populate a CustomerStuffDto with two values from a surgical, precise, fast query. Spring manages all the datasource and transaction stuff and wiring everything together, and it's easily JUnit tested (this is an "integration test" rather than "unit test" I am told, but it works !) Pretty sure ibatis helps you avoid the counting ? chars by naming params in a #param1# syntax, might be mis-recalling though.
fusiongyro 13y ago
You're absolutely right. In fact, our application has a pretty severely hierarchical nature. Initially, we just pulled out the top-level things and let Hibernate handle it, but performance was ghastly. We added a native query to pull out the first four levels at once, and a great deal of manual code in Java to process what came out. This is good, but the fifth level is self-referencing and recursive. I have an SQL query now that can retrieve everything at once, but the amount of Java code I'm going to have to write to drop it in is a significant barrier. Still, once I do, most of our egregious performance problems will be solved. You can make it work. But I think Hibernate and other ORMs work by selling you on the notion that they're an abstraction, that you don't have to know everything to use them. In my experience, Hibernate winds up creating a third domain of necessary expertise, rather than managing the two so you only have to have one. And this is the source of the anger.
- brianmcc 13y ago
  One observation - seems you can almost predict people's preference for Hibernate or Ibatis (or something else) based on whether they are "application folk", who see the DB as just the persistence mechanism, or whether they view the DB as the "critical data store" with the application used to get and store that data. Despite being very much an app developer myself, not a DBA or particularly a DB development guy, I've seen DBs outlast many apps, coding languages etc, and always feel it's the most important thing at the end of the day. Depends on your domain too I guess, I'm sure there are many important exceptions.

nobullet 13y ago

I understand why people don't like ORMs. But I don't understand people who like iBatis: it is boilerplate like the hell. Imaging you have to separately update mappings for SQL select, insert, update and delete query (and these mappings are very long) for your entities. For example, prepared statement for update looks like this: PreparedStatement ps = ...; ps.setLong(1, author.getUserId()); ps.setLong(2, author.getStreamId()); ps.setString(3, author.getNetwork()); ps.setString(4, author.getIdInNetwork()); ps.setString(5, author.getNote()); ps.setString(6, author.getSocialId()); .... And manually counting questions is a normal practice when you add a field: static final String UPDATE = "UPDATE Table1 SET Domains = ?, TemplateId = ?, InternalJson = ? WHERE StreamID = ?"; static final String INSERT = "INSERT INTO Config1 (UserID, StreamID, Domains, TemplateId, InternalJson) VALUES (?, ?, ?, ?, ?)";

fusiongyro 13y ago
You have to pick your battles. It's convenient that Hibernate will do these things for you, but I have seen lots of times when the order Hibernate wants to remove something causes an integrity violation. For instance, a not-null foreign key reference in a linking table; sometimes Hibernate seems to try setting the value to null before deleting the referenced entity, leading to an integrity violation. There have been times when I couldn't figure out how to make Hibernate do this the right way (reversing the order of its deletes and skipping the unnecessary set-null step) so I instead just lifted the constraint. I hate when I have to do that, because ideally Hibernate should just live with whatever schema I have given it. Another example is trying to depend on CASCADE in the database. The settings you need to make to get Hibernate to accept this are quite arcane and force you to manually worry about list indexes in the Java code. Yet another example of a place where Hibernate, which ought not be telling me how to make my database or my Java code, instead winds up forcing me to take certain decisions in both.
brianmcc 13y ago
I can see your point, pretty valid. I guess I prefer control over magic. I can produce a complex SQL SELECT, use functions/joins/views, and populate either full entities with it or just teeny tiny DTOs, e.g. if I just need customer name and account number I can easily populate a CustomerStuffDto with two values from a surgical, precise, fast query. Spring manages all the datasource and transaction stuff and wiring everything together, and it's easily JUnit tested (this is an "integration test" rather than "unit test" I am told, but it works !) Pretty sure ibatis helps you avoid the counting ? chars by naming params in a #param1# syntax, might be mis-recalling though.

fusiongyro 13y ago

You're absolutely right. In fact, our application has a pretty severely hierarchical nature. Initially, we just pulled out the top-level things and let Hibernate handle it, but performance was ghastly. We added a native query to pull out the first four levels at once, and a great deal of manual code in Java to process what came out. This is good, but the fifth level is self-referencing and recursive. I have an SQL query now that can retrieve everything at once, but the amount of Java code I'm going to have to write to drop it in is a significant barrier. Still, once I do, most of our egregious performance problems will be solved. You can make it work. But I think Hibernate and other ORMs work by selling you on the notion that they're an abstraction, that you don't have to know everything to use them. In my experience, Hibernate winds up creating a third domain of necessary expertise, rather than managing the two so you only have to have one. And this is the source of the anger.

brianmcc 13y ago
One observation - seems you can almost predict people's preference for Hibernate or Ibatis (or something else) based on whether they are "application folk", who see the DB as just the persistence mechanism, or whether they view the DB as the "critical data store" with the application used to get and store that data. Despite being very much an app developer myself, not a DBA or particularly a DB development guy, I've seen DBs outlast many apps, coding languages etc, and always feel it's the most important thing at the end of the day. Depends on your domain too I guess, I'm sure there are many important exceptions.