composite-key does not support null-values
Description
Attachments
Activity
Piotr Jagielski March 17, 2012 at 11:30 PM
I have exactly the same situation as in description - a db-view, which combines two tables by outer-join. In my case the only unique combination of columns contains a nullable column. I don't need primary key but Hibernate forces me to define one. Since this request is rejected then what is the correct way to handle such situation in Hibernate?
Steve Ebersole March 21, 2011 at 7:05 PM
Bulk closing stale resolved issues
ThijsT October 6, 2009 at 11:40 AM
A Nullable User Type that implements the strategy to select the null fields and replacing them by a default value.
ThijsT October 6, 2009 at 9:25 AM
You are right. Therefore, in my opinion null values in composite keys should be configurable in the case you want to support legacy schemes.
Paul Benedict October 5, 2009 at 6:41 PM
The definition of a key is for it to be identifiable. Since NULL means unknown, it is not identifiable. Keys, by their definition, shouldn't be nullable.
At present all legacy data with null-values in its composite-key could not be read properly by hibernate.
While hibernate processes the resultset it returns null for that record and steps over to the next one.
Think of a db-view, which combines two (or more) tables by outer-join.
(that seems only necessary for crude legacy data indeed... but it´s not that unusual as you think)
The workaround is to use a db-generated identifier for each view-record (ex. combining the nullable-id fields).
It would be fine, if hibernate is not reliant on that.
To allow having composite-keys with partly null-Values, you could think of moving the "unsaved-value"-attribute
of the "composite-key"-tag to "key-property|key-many-to-one"-Tags...?!
—
Mmmh... saw you´ve done something with "columnNullness" in ver 3.1beta2. Perhaps it is fixed in there...
also seen on