My answer is that if the code change looks too impactful I'm fine with no supporting such scenario.
On 11 Dec 2019, at 11:24, Joerg Baesner wrote: > > ... I suppose some means it as default. > > Yes, exactly. > > Your reply doesn't answer the question if Hibernate shouldn't support > this > scenario. Anyhow, what Gail already wrote is that Hibernate returns > null > for the entity result, leading to a null value in a returned > ResultList, > which seem to be wrong... > > On Wed, Dec 11, 2019 at 11:16 AM Emmanuel Bernard > <emman...@hibernate.org> > wrote: > >> We have been trying to keep a balance of maintainable code base for >> Hibernate vs legacy/counter intuitive/plain wrong DB designs. The >> answer is >> never clear cut. In your case I'm not sure what a bundle + key means >> if it >> does not have a locale - I suppose some means it as default. >> >> On 11 Dec 2019, at 10:49, Joerg Baesner wrote: >> >>> I think in the past we argued the same for attributes of a composite >>> id, >>> like you said, if one of the element can be nul, why is it in the id >>> property in the first place. >> >> As an example you might Imagine someone wants to put >> internationalization >> properties into a database and having a table structure like this >> (this >> might be an old legacy application that doesn't have a PK column): >> >> BUNDLE_NAME (not nullable) >> KEY (not nullable) >> LOCALE (nullable) >> VALUE (not nullable) >> >> The first 3 (BUNDLE_NAME, KEY, LOCALE) are the CompositeKey and >> there's a >> unique constraint on the database on these columns. >> >> It is fine to have the LOCALE as <null>, as in this case the systems >> default locale would be used, but for each BUNDLE_NAME/KEY >> combination you >> could only have a single composite key with a <null> LOCALE. >> >> Hibernate should be (must be?) able to handle this scenario, what do >> you >> think? >> >> Joerg >> >> On Wed, Dec 11, 2019 at 10:18 AM Emmanuel Bernard >> <emman...@hibernate.org> >> wrote: >> >>> Just talking about simple id, even if we allow the column to be >>> nullable >>> (if the DB even allows that), I don't think Hibernate allows null to >>> be >>> a valid id value. Because null means I don't know or not applicable. >>> I think in the past we argued the same for attributes of a composite >>> id, >>> like you said, if one of the element can be nul, why is it in the id >>> property in the first place. >>> >>> As for whether there is a strong implementation detail reason to not >>> allow it, I don't know but I assume the null checking assuming "not >>> an >>> id" is pretty much all over the place. >>> >>> Emmanuel >>> >>> On 11 Dec 2019, at 3:37, Gail Badner wrote: >>> >>>> Currently, there is no way to load an entity that exists in the >>>> database >>>> with a composite ID, if one of the composite ID columns is null. >>>> >>>> This behavior is due to this code in ComponentType#hydrate: >>>> >>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675 >>>> >>>> Basically, if any field/property in a composite ID is null, >>>> Hibernate >>>> assumes the entire ID is null. An entity cannot have a null ID, so >>>> it >>>> returns null for the entity result. >>>> >>>> I believe that Hibernate does allow a primary key column to be >>>> nullable. >>>> >>>> TBH, it seems strange to have a property in a composite ID that can >>>> be >>>> null. If it can be null, it seems that the property could be >>>> removed >>>> from >>>> the composite key. >>>> >>>> I don't see anything in the spec about a requirement that all >>>> composite ID >>>> fields/properties must be non-null. Am I missing something? >>>> >>>> The code I referenced above is 13 years old. Does anyone have >>>> insight >>>> into >>>> why Hibernate does this? >>>> >>>> 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 >>> >>> >> >> -- >> >> JOERG BAESNER >> >> SENIOR SOFTWARE MAINTENANCE ENGINEER >> >> Red Hat >> >> <https://www.redhat.com/> >> >> jbaes...@redhat.com T: +49-211-95439691 >> <https://red.ht/sig> >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >> >> > > -- > > JOERG BAESNER > > SENIOR SOFTWARE MAINTENANCE ENGINEER > > Red Hat > > <https://www.redhat.com/> > > jbaes...@redhat.com T: +49-211-95439691 > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
