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 <gbad...@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 <st...@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 <gbad...@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 <st...@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 <gbad...@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@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
