[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187?page=c... ] Emmanuel Bernard commented on HHH-5187: --------------------------------------- Today to merge an object graph, we load the object graph following the MERGE cascade settings allowing 1 query instead of multiple. This works well most of the time but can be surprising if the user expects lazy associations to not be loaded and if their side-effect loads triggers a performance hit. We can add a mapping to control this {code}@SkipJoinLoadOn({MERGE, REFRESH}){code} REFRESH and MERGE using the same algorithm. Note that the current algorithm is best most of the time: - it reduces the number of queries needed to merge an object graph - it limit the number of prepared queries (and thus memory consumption) Hibernate needs to keep (*) (*) if we load only associations marked as MERGE and not LAZY we need to create and keep : - two different queries assuming one association, - four different queries assuming two associations, etc... This is not realistic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187?page=c... ] Dirk commented on HHH-5187: --------------------------- I followed your discussion on this topic. "<epbernard> it all boils down to why this dud set the colelciton on LAZY while cascading MERGE" No dud. It all boils down to why you need to eagerly load an uninitialized collection on merge. @OneToMany(mappedBy = "master", cascade={CascadeType.MERGE, CascadeType.PERSIST}) should not be a problem but in your current implementation it is because CascadeType.MERGE forces it to load the collection though it was lazy. Me and many other users thought Hibernate JPA would ignore the CascadeType.MERGE in this case because (1) propagation of state makes no sense for a proxied collection and (2) it is against the spec. "<sebersole> i think it comes down to (1) do we violate the spec (i've seen nothing that says we do here) [11:31] <epbernard> sebersole: no clearly we don't violate the spec [11:31] <sebersole> (2) if not, do we "violate the spirit" by loading association [11:31] <sebersole> and if so (a) do we do so for valid reasons [11:32] <epbernard> and yes we violate in the spirit but as you said for good underlying reasons [11:32] <sebersole> ok" That is the funniest part. You are kidding yourselves. You might have good reasons for your "violation in spirit" but honestly - it is not according to the spec. So I do not think it is an user error in any way as you mentioned it. It is more driven by your design which enforces you to think about introducing a new mapping.. Any idea why EclipseLink does not need it!? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187?page=c... ] Dirk commented on HHH-5187: --------------------------- I would like to apologize for my harsh words. I felt myself offended when I read your discussion. I could not see any reason for a "user error" or why I was called dud. You would probably not like that either if you think you have nothing done wrong. So I was focused on that.. Anyway. Actually I pointed you to section 3.2.4.1 Merging Detached Entity State, p.51 in HHH-4135. I attached a JUnit test case, I mentioned that I also tested it with EclipseLink and that it behaves as expected. You closed it eagerly with a comment that surprised me and others. So what else do you expect I need to do here? What I really appreciate is that you discussed this in your team and elaborate on it. My hope was that no further mapping is needed and that CascadeType.MERGE is only considered for initialized entities. But ok, I see your optimization point and after knowing what you are doing here I understand now why Hibernate behaves this way. Nevertheless if you introduce a (optional) way to retain these non-initialized associations after merge I would definitively vote for it and I think many other Hibernate users as well. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187?page=c... ] Emmanuel Bernard commented on HHH-5187: --------------------------------------- @Dirk Gael did bring to my attention that I used the term "dud" where I really meant "dude" (familiar term for person but with no negative connotation in my mouth anyway). I initially did not react to the typo on IRC simply because I did not know the meaning of "dud". Now I know. Sorry for the confusion (me embarrassed). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira