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

[Joerg Baesner]

> ...  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 <emmanuel at 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 <emmanuel at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
> --
>
> JOERG BAESNER
>
> SENIOR SOFTWARE MAINTENANCE ENGINEER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> jbaesner at 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/>

jbaesner at redhat.com    T: +49-211-95439691
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>