[
https://issues.apache.org/jira/browse/CAY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840376#action_12840376
]
Andrus Adamchik commented on CAY-1398:
--------------------------------------
Wonder if we should force predictable (JDK-independent) iteration order of
properties on the class descriptors. This should have no per-query performance
impact (as descriptors are "compiled" once), and will ensure some consistency.
> ClassCastException on meaningful FK with non-standard Java to JDBC type
> mapping
> -------------------------------------------------------------------------------
>
> Key: CAY-1398
> URL: https://issues.apache.org/jira/browse/CAY-1398
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
> Affects Versions: 3.0RC2
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Priority: Minor
> Fix For: Short term future
>
>
> A rather odd case, that nevertheless we should handle:
> TABLE1 (PK INT, FK CHAR(1))
> TABLE2 (PK CHAR(1));
> Class1 (fk : java.lang.Character, class2: Class2)
> I.e. a relationship is mapped with FK also being a meaningful attribute, and
> attribute type is not a standard JDBC mapping of CHAR(1) column. Depending on
> the Class1 entity property iteration order, SelectTranslator builds a result
> column either from an "fk" attribute definition (then it is correctly mapped
> as java.lang.Character) or from "class2" relationship definition (which will
> end up ignoring ObjAttribute and using java.lang.String). Later on when a
> property is read from an object, the later case results in ClassCastException
> (of java.lang.String into java.lang.Character).
> This is almost impossible to test. For the entity in my project, switching
> between JDK 1.5 and 1.6 makes all the difference (it fails under 1.5, but
> this is really random, dependent on the relationship and attribute relative
> string key names).
> A quick (and incorrect) fix is to make
> SelectTranslator.appendQueryColumns(..) -> "visitRelationship" check for
> existence of ObjAttribute for the join DbAttribute to ensure the right type
> is used. Although this may result in invalid to-one fault ObjectIds, as the
> target entity may not have meaningful ID columns, and the ObjectId derived
> from FK will not match ObjectId of the target object fetched directly.
> A correct, but significantly deeper fix is to read the same ResultSet column
> twice, and put 2 copies in the DataRow: one for meaningful attribute, and one
> for generic FK. maybe all "attributeOverrides" in SelectTranslator should
> follow this approach (and also other places where we duplicate the same
> column in the ResultSet for consistency reasons)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
