I personally do not think it is correct to change the existing behavior here, but I do not have a strong feeling for it. I just believe that you don't change historical behaviors that work as designed except as protected by the setting to enable the new feature or improvement.
I really do not get the performance point you are making. You mean because of potential "extra" updates? Well, again that is the design, and from that perspective the app is misusing Hibernate. Whether the design is "correct" and whether the code properly works according to the design are 2 totally different discussions. As for 4.3.x, for me that again goes back to this not being a bug. 4.3 is a maintenance branch now, meaning it should only include bug fixes in any releases. So IMO this should not be part of the 4.3 branch. I do want to have a discussion about possibly doing another 4.x release as a sort of incremental stepping stone to the 5.0 work on master. The plan is to have that discussion next week, since quite a few of us will be meeting face to face. I can see this being a part of that new branch if we end up doing it. On Fri, Oct 24, 2014 at 9:14 AM, Guillaume Smet <guillaume.s...@gmail.com> wrote: > Hi Steve, > > On Fri, Oct 24, 2014 at 3:08 PM, Steve Ebersole <st...@hibernate.org> > wrote: > > As to your specific question, yes I think what you propose makes sense. > > Namely, if this setting is enabled, I think it is reasonable to treat a > null > > component reference and an empty component reference as equivalent. > > Thanks for your feedback! > > Isn't it even more reasonable to treat null and empty as equivalent in > the current behavior? > > Currently, we have: > Entity with empty embedded -> save + get -> Entity with null > so we are considering that empty embedded and null are the exact same > things. > > If you set again the embedded to an empty one for various reasons, > it's going to be considered dirty again which is IMHO wrong. > > I won't argue a lot about this as we will run all our applications > with this setting enabled but I think it will be a performance > improvement to fix this in the other case too. > > > Note that I'm not very familiar with these things so I might have > missed an obvious point. > > We are going to fix the things you commented on Github, work on the > documentation and wait for your feedback on this specific point before > going further on this particular issue. > > It would be nice to have it in the next 4.3.x release as we have an > application which is particularly affected by this issue. > > -- > Guillaume > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev