[ https://issues.jboss.org/browse/TEIIDDES-2256?page=com.atlassian.jira.plu... ] Ramesh Reddy edited comment on TEIIDDES-2256 at 8/28/14 11:21 PM: ------------------------------------------------------------------ [~van.halbert] I am not sure what you are disagreeing with nor the motivation behind feature request for TEIIDDES-2238 Let me see if I can recap.. Teiid exposes a limited set of runtime types, they have *defined* mappings to Design time data types in designer. Each design time data type also for modeling validation purposes map to XSD types. The core of *this* issue is, currently the mapping of integer is DT --> XSD --> RUNTIME integer --> xs:integer --> biginteger Which is wrong. I am saying it should be integer --> xs:long --> integer int --> xs:long --> integer biginteger --> xs:integer --> biginteger Now the mapping happens automatically during the import, because those are the types that Server defined according to the metadata exposed by the translator. If user changes the data type in the Designer, and not proper "convert" functions available then the query is certain to fail. So by default, we should map exactly as defined by translator. I do not see a need to provide a mapping *per* source that differs from translator type by default, which I see as gist of TEIIDDES-2238. BTW user can change data type manually anytime they want, I am not sure what is being mentioned in JBDVPL-149 which is not at all clear for me in its intent. was (Author: rareddy): [~van.halbert] I am not sure what you are disagreeing with nor the motivation behind feature request for TEIID-2238 Let me see if I can recap.. Teiid exposes a limited set of runtime types, they have *defined* mappings to Design time data types in designer. Each design time data type also for modeling validation purposes map to XSD types. The core of *this* issue is, currently the mapping of integer is DT --> XSD --> RUNTIME integer --> xs:integer --> biginteger Which is wrong. I am saying it should be integer --> xs:long --> integer int --> xs:long --> integer biginteger --> xs:integer --> biginteger Now the mapping happens automatically during the import, because those are the types that Server defined according to the metadata exposed by the translator. If user changes the data type in the Designer, and not proper "convert" functions available then the query is certain to fail. So by default, we should map exactly as defined by translator. I do not see a need to provide a mapping *per* source that differs from translator type by default, which I see as gist of TEIIDDES-2238. BTW user can change data type manually anytime they want, I am not sure what is being mentioned in JBDVPL-149 which is not at all clear for me in its intent. -- This message was sent by Atlassian JIRA (v6.3.1#6329)