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

[Emmanuel Bernard]

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

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

[Joerg Baesner]

> 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 , 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  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 
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



jbaes...@redhat.comT: +49-211-95439691

TRIED. TESTED. TRUSTED. 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [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 , 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  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 
> 
> 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
>
> 
>
> jbaes...@redhat.comT: +49-211-95439691
> 
> TRIED. TESTED. TRUSTED. 


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [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 
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 , 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  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 
> 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
>
> 
>
> jbaes...@redhat.comT: +49-211-95439691
> 
> TRIED. TESTED. TRUSTED. 
>
>

-- 

JOERG BAESNER

SENIOR SOFTWARE MAINTENANCE ENGINEER

Red Hat



jbaes...@redhat.comT: +49-211-95439691

TRIED. TESTED. TRUSTED. 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Emmanuel Bernard]

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 
> 
> 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 , 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  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 
>> 
>> 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
>>
>> 
>>
>> jbaes...@redhat.comT: +49-211-95439691
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>>
>
> -- 
>
> JOERG BAESNER
>
> SENIOR SOFTWARE MAINTENANCE ENGINEER
>
> Red Hat
>
> 
>
> jbaes...@redhat.comT: +49-211-95439691
> 
> TRIED. TESTED. TRUSTED. 


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev