Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HHH-7610 Add an option to initialize empty components when all the pr… #1080

Merged
merged 1 commit into from
Jan 24, 2016

Conversation

gsmet
Copy link
Member

@gsmet gsmet commented Sep 15, 2015

…operties are null

Note that this commit also changes the semantic of the comparison between a null component
and a component with all properties null: they are considered equivalent.

@@ -176,9 +176,7 @@ public boolean isEqual(final Object x, final Object y) throws HibernateException
if ( x == y ) {
return true;
}
if ( x == null || y == null ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these changes be considered only when this opt-in setting is enabled? Meaning, to me, I think the setting we add ought to be a gate-keeper between we want the original behavior (default) and we want this new behavior (opt-in).

But as it is, these changed checks for isEqual, isDirty, etc all now happen regardless of whether we opted into the "new behavior"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we did that on purpose as we think it is a bug in the current behavior.

With the current behavior, when you persist your entity with an empty embedded and you get it back the embedded is null. So we think in this case, the empty embedded and null should be considered equal.

I can change it if you think it's better to keep the old behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok that makes sense, to make the handling reflexive. I'm ok with keeping this.

Could you please look into the conflicts though. Thanks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. It was a new conflict in AvailableSettings as there were new changes since my last rebase.

…operties are null

Note that this commit also changes the semantic of the comparison between a null component
and a component with all properties null: they are considered equivalent.
@sebersole sebersole self-assigned this Jan 24, 2016
@sebersole sebersole merged commit d71f931 into hibernate:master Jan 24, 2016
@sebersole
Copy link
Member

Applied this upstream. Thanks Guillaume!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants