Re: [hibernate-dev] Composite IDs with a null property/field

... I suppose some means it as default.

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 <emmanuel(a)hibernate.org&gt; 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... > > > > 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- JOERG BAESNER SENIOR SOFTWARE MAINTENANCE ENGINEER Red Hat <https://www.redhat.com/> jbaesner(a)redhat.com T: +49-211-95439691 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>