You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (JIRA)" <ji...@apache.org> on 2010/02/25 17:32:28 UTC
[jira] Created: (CAY-1398) ClassCastException on meaningful FK with
non-standard Java to JDBC type mapping
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.
Fwd: [jira] Commented: (CAY-1398) ClassCastException on meaningful FK with non-standard Java to JDBC type mapping
Posted by Andrus Adamchik <an...@objectstyle.org>.
FYI: I think this is pretty important to fix. Hope that doesn't create
many regression issues for the current 3.0 users. Or maybe this would
be a good thing, as it will uncover subtle bugs that were hidden by
JDK-specific key iteration order.
Andrus
Begin forwarded message:
> 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.
[jira] Commented: (CAY-1398) ClassCastException on meaningful FK
with non-standard Java to JDBC type mapping
Posted by "Andrus Adamchik (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CAY-1398) ClassCastException on meaningful FK with
non-standard Java to JDBC type mapping
Posted by "Andrus Adamchik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrus Adamchik updated CAY-1398:
---------------------------------
Description:
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)
was:
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.
> 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.