About the order of SQL execution when flushing to the database

Hibernate ORM
22

I read it only for how the unidirectional associations work. Regarding this, the code

Post post = new Post("First post");
 
post.getComments().add(
    new PostComment("My first review")
);
post.getComments().add(
    new PostComment("My second review")
);
post.getComments().add(
    new PostComment("My third review")
);

according to code change order would result in the following SQL

insert into post (title, id) 
values ('First post', 1)
 
insert into post_comment (review, id) 
values ('My first review', 2)

update post_comment set post_id = 1 where id = 2
 
insert into post_comment (review, id) 
values ('My second review', 3)
 
update post_comment set post_id = 1 where id =  3

insert into post_comment (review, id) 
values ('My third review', 4)

update post_comment set post_id = 1 where id =  4

in which case there are no constraint violation issues, consequently this example does not qualify to demonstrate that Hibernateā€™s flush order is doing something special regarding preventing constraint violations.

I will wait for you to perhaps clarify this situation, or get me another example.

For point 3), I will wait for you to show me too.

Regarding ā€œmulti-request logical transactionsā€ I will read it, then come back if anything relates to this topic.

23

Iā€™ll give you those examples after you send me that Pull Request with the flush method call that really makes sense.

24

I donā€™t remember proposing a ā€œflush method call that really makes senseā€ ā€¦ I just do not agree that calling flush manually is always a code smell, and do not agree that using update in place of delete and insert is always the best option.

In fact, the discussion around manual flush smells was divergent to my goal when creating this topic:

I just want to understand the reason behind Hibernateā€™s flush order, which ā€œwas chosen to minimize the chances of constraint violationsā€.

Put simply: no evidence of Hibernateā€™s flush order avoiding constraint violations was presented yet. This evidence must show Java code, and the corresponding SQL, the latter ordered as per Hibernateā€™s flush order and avoiding a constraint violation that would occur if the SQL was flushed as per change order.

Please, lets focus on this, and forget the side-talk of code smells.

25

Only Gavin knows exactly why they implemented the ActionQueue like this 17 years ago. You should ask him on Twitter and see whether he gives you a more detailed explanation.

Iā€™m going to end this topic since thereā€™s nothing to add on my side.

Good luck digging the history of this design consideration. If you find a different explanation than what I already have you, you should definitely add it here or write an article about it. Anyway, no matter what the reason was, itā€™s unlikely that it will ever change, so better understand how it works and how to get the most out of it.

Cheers

26

Thank you for your assistence trying to understand this better.

Best Regards,

1 Like