Andrus Adamchik created CAY-2888:
------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
