[ https://issues.jboss.org/browse/TEIID-2083?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-2083: ----------------------------------- various issues were resolved with TEIID-2103, but non-runtime type handling is still an issue. for now when a non-runtime type (marked as Basic in the metadata) is used we use the runtime type as the type name and add a custom UDT property with the datatype name, length, precision, and scale. At the very least the parser needs support for that, which would get us to all known designer built-in types. However any enterprise types would still be an issue. Right now datatypes are not schema scoped entries and do not have export sql, so there's no export of the enterprise type information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2083?page=com.atlassian.jira.plugin... ] Akshay Harale commented on TEIID-2083: -------------------------------------- hey I need this quickly is it avilable right now in teiid 8.1 ? Because I want to know MetaData of deployed Models having XML data source will that possible by using this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2083?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2083: --------------------------------------- Ramesh, there are a couple of things that we could do. What is stubbed in right now is a UDT option clause option, where the name value pair is UDT=typename(length, precision, scale) and the runtime type is used for the actual type declaration. That is consistent with the current parser implementation. If we add handling for that option, then we would be able to override the runtime type with the given built-in/enterprise type. Assuming that the type is known - which it should be in the case of built-in types. The other route is to change the parser to allow for any identifier as the type name. As you are indicating a new keyword may be needed in the latter case since there are conflicts between the built-in type names and the runtime type name (the built-in type integer != our 4 byte integer) since the built-in types are coming from xsd types. The other part of this is that sense the enterprise types are not in any schema and we lack a DDL form, there isn't a method for getting enterprise type definitions (which are typically only used in xml scenarios though). We could add another method such as getDatatypes or implicitly scope the datatypes to the SYS schema and add them as a SchemaObjectType. Either way we'd still have to define the DDL for retrieving them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2083?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-2083. --------------------------------- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira