[hibernate-dev] HHH-7610 Embedded: emptiness and dirtiness

[Steve Ebersole]

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.smet at gmail.com>
wrote:

> Hi Steve,
>
> On Fri, Oct 24, 2014 at 3:08 PM, Steve Ebersole <steve at 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
>