[
https://issues.apache.org/jira/browse/CAY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-2888:
---------------------------------
Description:
Just ran into a specific mapping scenario that results in occasional resolving
of a to-one relationship as "null" when it is not null in the DB.
Mapping:
* Entity A has a compound PK (3 columns, one of them is KEY1 CHAR(1)... this is
likely the only one that is relevant, as described below)
* Entity B has a to-one relationship to A with a 3-column FK
* Both Entity A and B have their corresponding KEY1 column mapped as an
ObjAttribute (this is not a recommended way of mapping for the FK, but it is
useful and justified here. The whole thing is read-only)
* (!!!) It is mapped as a "java.lang.String" on the B side, and as "char" on
the A side
When calling "b.a()" for a non-null relationship, sometimes we get a value,
other times - a null. The outcome depends on the state of the cache. The last
point ("java.lang.String" vs "char" ObjAttribute type mismatch) seems to be the
culprit. Once we remapped "char" to "String", the problem went away.
Debugging showed that if A was first accessed via a relationship from B, its
ObjectId contained KEY1 as a String value (clearly incorrect, but *appeared* ok
in the app), whereas if it is previously read directly via a query, its cached
snasphot had an ObjectId with KEY1 of type "java.lang.Character", which was
correct, but resulted in "b.a()" resolving as null later.
So how we build an ObjectId from an FK is the problem in case of ObjAttribute
type mismatch. A fix would likely require value type transformation in cases of
such sloppy mapping.
was:
Just ran into a specific mapping scenario that results in occasional resolving
of a to-one relationship as "null" when it is not null in the DB.
Mapping:
* Entity A has a compound PK (3 columns, one of them is KEY1 CHAR(1)... this is
likely the only one that is relevant, as described below)
* Entity B has a to-one relationship to A with a 3-column FK
* Both Entity A and B have their corresponding KEY1 column mapped as an
ObjAttribute (this is not a recommended way of mapping for the FK, but it is
useful and justified here. The whole thing is read-only)
* (!!!) It is mapped as a "java.lang.String" on the B side, and as "char" on
the A side
When calling "b.a()" for a non-null relationship, sometimes we get a value,
other times - a null. The outcome depends on the state of the cache. The last
point ("java.lang.String" vs "char" ObjAttribute type mismatch) seems to be the
culprit. Once we remapped "char" to "String", the problem went away.
Debugging showed that if A was first accessed via a relationship from B, its
ObjectId contained KEY1 as a String value (clearly incorrect, but *appeared* ok
in the app), whereas if it is previously read directly via a query, its cached
snasphot has an ObjectId where KEY1 was a java.lang.Character, which was
correct, but resulted in "b.a()" resolving as null.
So how we build an ObjectId from an FK is the problem in case of ObjAttribute
type mismatch. A fix would likely require value type transformation in cases of
such sloppy mapping.
> Meaningful PK relationship occasionally incorrectly resolves to null
> --------------------------------------------------------------------
>
> Key: CAY-2888
> URL: https://issues.apache.org/jira/browse/CAY-2888
> Project: Cayenne
> Issue Type: Bug
> Affects Versions: 4.2.2
> Reporter: Andrus Adamchik
> Priority: Minor
>
> Just ran into a specific mapping scenario that results in occasional
> resolving of a to-one relationship as "null" when it is not null in the DB.
> Mapping:
> * Entity A has a compound PK (3 columns, one of them is KEY1 CHAR(1)... this
> is likely the only one that is relevant, as described below)
> * Entity B has a to-one relationship to A with a 3-column FK
> * Both Entity A and B have their corresponding KEY1 column mapped as an
> ObjAttribute (this is not a recommended way of mapping for the FK, but it is
> useful and justified here. The whole thing is read-only)
> * (!!!) It is mapped as a "java.lang.String" on the B side, and as "char" on
> the A side
> When calling "b.a()" for a non-null relationship, sometimes we get a value,
> other times - a null. The outcome depends on the state of the cache. The last
> point ("java.lang.String" vs "char" ObjAttribute type mismatch) seems to be
> the culprit. Once we remapped "char" to "String", the problem went away.
> Debugging showed that if A was first accessed via a relationship from B, its
> ObjectId contained KEY1 as a String value (clearly incorrect, but *appeared*
> ok in the app), whereas if it is previously read directly via a query, its
> cached snasphot had an ObjectId with KEY1 of type "java.lang.Character",
> which was correct, but resulted in "b.a()" resolving as null later.
> So how we build an ObjectId from an FK is the problem in case of ObjAttribute
> type mismatch. A fix would likely require value type transformation in cases
> of such sloppy mapping.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
