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