-
Bug
-
Resolution: Done
-
Major
-
8.4
-
None
-
None
1) Open attached project in Designer
2) Deploy the BQT2.vdb
3) Create another project
4) Import the VDB metadata via JDBC Importer into your second project (will end up being a read-only VDB source model)
5) On finish you'll get an exception when processing the type_varbinary column because the type returned is "0" and type name of "null"
java.lang.IllegalArgumentException: Expected argument to be non-null but got null at org.teiid.core.designer.util.CoreArgCheck.isNotNull(CoreArgCheck.java:142) at org.teiid.core.designer.util.CoreArgCheck.isNotNull(CoreArgCheck.java:128) at org.teiid.designer.sdt.types.BuiltInTypesManager.getBuiltInDatatype(BuiltInTypesManager.java:477) at org.teiid.designer.sdt.types.WorkspaceDatatypeManager.getBuiltInDatatype(WorkspaceDatatypeManager.java:94) at org.teiid.designer.jdbc.relational.impl.RelationalModelProcessorImpl.findType(RelationalModelProcessorImpl.java:1450) at org.teiid.designer.jdbc.relational.impl.RelationalModelProcessorImpl.setColumnInfo(RelationalModelProcessorImpl.java:1321)
[TEIID-2833] While importing from Deployed BQT2 VDB, JDBC type of 0 and type name NULL was returned for column with design-time type varbinary
Filip Elias <felias@redhat.com> changed the Status of bug 1060335 from ON_QA to VERIFIED
Julian Coleman <jcoleman@redhat.com> changed the Status of bug 1060335 from MODIFIED to ON_QA
jolee@redhat.com changed the Status of bug 1060335 from NEW to MODIFIED
Steven Hawkins
added a comment - switched to using the same uuid as designer Steven Hawkins
added a comment - Moved back to Teiid to use a different uuid. I think the reason we are not throwing an exception in the first place when we can't find the type has to do with old user defined scenarios in which it seemed like the referenced datatype was not known.
Steven Hawkins
added a comment - Moved back to Teiid to use a different uuid. I think the reason we are not throwing an exception in the first place when we can't find the type has to do with old user defined scenarios in which it seemed like the referenced datatype was not known. 
Barry LaFond
added a comment - I'm good with using our UUID (above) and moving on.
There are a handful of spots in our transformation code that uses our runtime type. Would be risky at this time to change the runtime types on our side.
Barry LaFond
added a comment - I'm good with using our UUID (above) and moving on.
There are a handful of spots in our transformation code that uses our runtime type. Would be risky at this time to change the runtime types on our side. Steven Hawkins
added a comment - > That is the incorrect runtime type, unless the meaning in this file is the xsd/xml representation.
I should add that from a runtime perspective, we ignore the runtime type set by designer and override it with the one from the datatypes.dat mapping. So if you need to leave this as string for whatever reason that would be fine.
I can then move this issue back to Teiid if all we need to do is use the uuid from above.
Steven Hawkins
added a comment - > That is the incorrect runtime type, unless the meaning in this file is the xsd/xml representation.
I should add that from a runtime perspective, we ignore the runtime type set by designer and override it with the one from the datatypes.dat mapping. So if you need to leave this as string for whatever reason that would be fine.
I can then move this issue back to Teiid if all we need to do is use the uuid from above. Steven Hawkins
added a comment - > Note the runtime type is string as it is for base64Binary, hexBinary and others
That is the incorrect runtime type, unless the meaning in this file is the xsd/xml representation.
> The UUIDs all seem to match up with your types.dat except for varbinary
Yes it looks like we used different versions. The initial Teiid check in was from July and this one is from August. If that is the only UUID designer knows, then I will update the Teiid side.
Steven Hawkins
added a comment - > Note the runtime type is string as it is for base64Binary, hexBinary and others
That is the incorrect runtime type, unless the meaning in this file is the xsd/xml representation.
> The UUIDs all seem to match up with your types.dat except for varbinary
Yes it looks like we used different versions. The initial Teiid check in was from July and this one is from August. If that is the only UUID designer knows, then I will update the Teiid side. Our datatype schema is here: https://github.com/Teiid-Designer/teiid-designer/blob/master/plugins/org.teiid.designer.sdt/builtInDataTypes.xsd
The varbinary is defined as:
<xs:simpleType mmedt:UUID="mmuuid:606b7f4f-08a2-4072-86e2-9915f3952c7d" mmedt:runtimeDataType="string" mmedt:runtimeDataTypeFixed="false" name="varbinary"> <xs:annotation> <xs:documentation> The runtime type is a byte[] wrapper called BinaryType</xs:documentation> </xs:annotation> <xs:restriction base="xs:base64Binary"/> </xs:simpleType>
- Note the runtime type is string as it is for base64Binary, hexBinary and others
- The UUIDs all seem to match up with your types.dat except for varbinary
Barry LaFond
added a comment - - edited Our datatype schema is here: https://github.com/Teiid-Designer/teiid-designer/blob/master/plugins/org.teiid.designer.sdt/builtInDataTypes.xsd
The varbinary is defined as:
<xs:simpleType mmedt:UUID= "mmuuid:606b7f4f-08a2-4072-86e2-9915f3952c7d" mmedt:runtimeDataType= "string" mmedt:runtimeDataTypeFixed= "false" name= "varbinary" >
<xs:annotation>
<xs:documentation> The runtime type is a byte[] wrapper called BinaryType </xs:documentation>
</xs:annotation>
<xs:restriction base= "xs:base64Binary" />
</xs:simpleType>
Note the runtime type is string as it is for base64Binary , hexBinary and others
The UUIDs all seem to match up with your types.dat except for varbinary
jolee@redhat.com changed the Status of bug 1060335 from VERIFIED to CLOSED