[hibernate-dev] Null vs "empty" embeddable values

[Steve Ebersole]

It's absolutely enough.  It's a best effort.

I, for sure, do not want us checking this each and every time we need to
check.  That's excessively unwarranted.

On Wed, Jul 26, 2017, 6:45 PM Gail Badner <gbadner at redhat.com> wrote:

> IIUC, the fix for HHH-7610 was supposed to have Hibernate treat null and
> empty composite as equivalent, regardless of how hibernate.create_empty_composites.enabled
> is set. [1]
>
> The application could instantiate empty embeddables itself, and Hibernate
> should still treat those values as equivalent to null.
>
> Is it really enough to check that the composite overrides equals/hashCode
> (without actually finding out if (!emptyValue.equals( null ) ||
> emptyValue.hashCode() != 0)?
>
> I think documentation would help.
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1080
>
> On Wed, Jul 26, 2017 at 4:21 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> No I mean checking on start up similar to what we do for composite id
>> classes.  So basically if this setting is enabled (treat all nulls == empty
>> composite) make sure that the composite overrides equals/hashCode.
>>
>>
>>
>> On Wed, Jul 26, 2017 at 6:08 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Hi Steve,
>>>
>>> IIUC, you are suggesting:
>>>
>>> if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
>>>      LOG.warn( ... );
>>> }
>>>
>>> I originally mentioned this issue with respect to Collection methods
>>> called on collections of embeddable values, but it could apply to
>>> empty/null embeddables in singular attributes as well.
>>>
>>> This warning would apply regardless of the setting for
>>> hibernate.create_empty_composites.enabled, since an application itself
>>> could set null or empty embeddable values.
>>>
>>> After thinking about this more, I suspect that such a warning would get
>>> logged for many (most?) embedded values.
>>>
>>> There is also a complication that Hibernate will inject the parent into
>>> an empty value if @Parent is mapped on a property in the embeddable. That
>>> (non-empty) parent could affect what gets returned by #equals and/or
>>> #hashCode.
>>>
>>> I've been trying to figure out a good place for checking to minimize the
>>> warnings.
>>>
>>> Here are some options:
>>>
>>> 1) Check when the owner PersistentClass is being validated by
>>> MetadataImpl#validate.
>>>
>>> Component#validate could be added to override SimpleValue#validate. If
>>> the check fails, a warning will logged in each context where the embeddable
>>> is used.
>>>
>>> Unfortunately, if @Parent is used in the embeddable class, there would
>>> be no way to check if parent attribute affects #equals or #hashCode since
>>> there is (obviously) no parent when validating the PersistentClass.
>>>
>>> 2) Check after Hibernate instantiates an empty value when resolving a
>>> null value with hibernate.create_empty_composites.enabled=true  by
>>> ComponentType#resolve(Object value, SharedSessionContractImplementor
>>> session, Object owner).
>>>
>>> I believe the parent would be provided to the method, so it would be
>>> available to check. I'd have to check to be sure though.
>>>
>>> If the parent contributes to the return values of #equals or #hashCode,
>>> there are other considerations to take into account.
>>>
>>> At the time ComponentType#resolve is called, the parent may not be
>>> completely resolved; it may not be valid to call those methods when the
>>> component is being resolved.
>>>
>>> Calling #hashCode and #equals on the parent each time Hibernate
>>> instantiates an empty value when resolving a null value (with
>>> hibernate.create_empty_composites.enabled=true) could hurt performance.
>>>
>>> If the check fails, lots of warnings could be logged.
>>>
>>> My opinion...
>>>
>>> After thinking about this as I'm writing this, I think 1) makes sense if
>>> there is no parent; 2) has too many problems to be workable.
>>>
>>> Any other ideas about how to deal with this?
>>>
>>> I don't think there is anything in the user guide that discusses how
>>> Hibernate treats null and empty embeddables as equivalent. There have been
>>> issues reported periodically related to collections. The most recent
>>> is HHH-11723. I think it would be worthwhile documenting this
>>> information in the user guide.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Gail
>>>
>>> On Wed, Jul 26, 2017 at 6:01 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> "Requirement" - no.  I think a warning in this case is perfectly fine.
>>>>
>>>> As for JPA, it says nothing about embeddables and nulls.
>>>>
>>>> On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>>> As of HHH-7610, Hibernate is supposed to treat null and empty
>>>>> embeddable
>>>>> values as equivalent.
>>>>>
>>>>> Should we add a requirement that an embeddable class #equals and
>>>>> #hashCode
>>>>> methods also treats null and "empty" values as equivalent?
>>>>>
>>>>> That would mean that #hashCode returned for all empty embeddables
>>>>> should be
>>>>> 0, and embeddableValue.equals( null ) should return true for all empty
>>>>> embeddableValue.
>>>>>
>>>>> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
>>>>> persisted for Set elements (they already were not persisted for bags,
>>>>> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which
>>>>> would
>>>>> no longer persist empty embeddable values and would ignore embeddables
>>>>> with
>>>>> all null columns when initializing collections.
>>>>>
>>>>> I don't think JPA has any such requirement, and I'm hesitant to enforce
>>>>> something that may be at odds with JPA.
>>>>>
>>>>> Comments or opinions?
>>>>>
>>>>> Thanks,
>>>>> Gail
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>