I agree with Steve. I don't think that we should add a feature to
explicitly support this.
That said, there is a workaround that avoids the issue, by using a UserType
to convert null to an empty string for Java processing, and convert the
empty string to null for inserting, update, and deleting.
I've already chimed in ;)
I don't think this is something we should do.
On Wed, Dec 18, 2019, 3:44 PM Gail Badner wrote:
> The main obstacle I see is that Hibernate assumes that ID columns are
> non-nullable, even if ID columns are explicitly mapped as nullable.
>
> This is consistent with the
The main obstacle I see is that Hibernate assumes that ID columns are
non-nullable, even if ID columns are explicitly mapped as nullable.
This is consistent with the JPA spec, which says:
"Every entity must have a primary key."
ANSI SQL 92 says:
"In addition, if the unique constraint was define
Jan-Willem, thanks very much for your feedback!
You may be right about Hibernate not allowing a formula for a composite ID
property. It appears it's not allowed when hbm mapping is used. I'll have
to check to see if a formula is allowed when mapped with annotations..
Looking a the mapping for Add
PostgreSQL doesn’t allow nullable columns in a compound primary key. It allows
a unique constraint on a nullable column, but then it happily inserts the two
values below - without constraint violation error.
I too have stumbled upon the need for nullable identifiers in Hibernate
however. Mostly
I've confirmed that the same inserts result in a constraint violation using
Oracle 12c:
insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);
insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);
I'm trying to figure out what would be needed to su
Thinking about this more, I realized that, depending on the database, the
use case may be invalid.
For H2, at least, the following is allowed with a unique constraint:
insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);
insert into bundle (BUNDLE_NAME, KEY, LOCALE) valu
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
> sc
> ... 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 wr
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,
> 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 s
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
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/ty
13 matches
Mail list logo
