3 ms·

> But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted i

> But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE statement for each child row. I’m sure there are loads of good reasons why it did that, but it’a not something that you’d even consider in pure SQL. IIRC, it does that if you use Lists instead of Sets. https://dzone.com/articles/best-performance-practices-for-hibernate-5-and-spr https://dzone.com/articles/best-performance-practices-for-hi...

doctor_eval 6y ago
Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?!
- tablespoon 6y ago
  > Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?! Yeah, it seems a little bonkers on first glance and I haven't ever dug in to see if there was a justifiable reason or not. IIRC, if you just need ordering, you could just use an SortedSet. I think technically lists are for when you need ordering and duplicates.
  - doctor_eval 6y ago
    Yeah it is bonkers! Not just at first glance. The fact that the SQL integration for the child object behaves differently based on the kind of collection used in the parent is exactly the kind of unintuitive behaviour that drove me nuts. There are so many rules to remember for something that is supposed to make SQL integration natural.
Ygg2 6y ago
Sets in Hibernate suffer because you can store an object before it was updated and Hibernate will update it. E.g. If say Person { id: Integer, name: String } Let's say I have some entity that stores Persons as HashSet. If I add them before saving, their hash set is taken without Id. Id can be automatically generated by Hibernate on save/create. After save the Id now has a new value. I.e. its hash differs from when it was saved. Boom. You have HashSet with Zombie entries. That are technically that you can't fetch actually.

doctor_eval 6y ago

Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?!

tablespoon 6y ago
> Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?! Yeah, it seems a little bonkers on first glance and I haven't ever dug in to see if there was a justifiable reason or not. IIRC, if you just need ordering, you could just use an SortedSet. I think technically lists are for when you need ordering and duplicates.
- doctor_eval 6y ago
  Yeah it is bonkers! Not just at first glance. The fact that the SQL integration for the child object behaves differently based on the kind of collection used in the parent is exactly the kind of unintuitive behaviour that drove me nuts. There are so many rules to remember for something that is supposed to make SQL integration natural.

Ygg2 6y ago

Sets in Hibernate suffer because you can store an object before it was updated and Hibernate will update it. E.g. If say Person { id: Integer, name: String } Let's say I have some entity that stores Persons as HashSet. If I add them before saving, their hash set is taken without Id. Id can be automatically generated by Hibernate on save/create. After save the Id now has a new value. I.e. its hash differs from when it was saved. Boom. You have HashSet with Zombie entries. That are technically that you can't fetch actually.