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

[Emmanuel Bernard]

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>