cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] Created: (CAY-1398) ClassCastException on meaningful FK with non-standard Java to JDBC type mapping
Date Thu, 25 Feb 2010 16:32:28 GMT
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.


Mime
View raw message