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 ready from the 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 dependent on the relationship and attribute string key names). 

A quick (and probably incorrect) fix is to make 
SelectTranslator.appendQueryColumns(..) -> "visitRelationship" check for 
existence of ObjAttribute for the join DbAttribute to ensure the right type is 
selected. 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 somewhat deep fix , would be 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.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to