4 ms·

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 m

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