[
https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-3429:
-------------------------------------
However if we are going that far, then it may be just as well to not
route this logic through the translator at all and just introduce some light weight
remoting logic such that the Designer can >get at the metadata facilities of the
relevant connection directly.
No, we do not want to manage another layer like translators for metadata.
Let me iterate the flow from view of Designer you are saying
1) Designer --> makes a admin connection
2) Designer --> deploys a dummy vdb that does not do metadata load
3) Designer --> makes JDBC connection
4) Designer --> using jdbc connection queries "getCatalog", then
"getSchema", then "getTables" etc.
5) Designer --> makes it's selections and creates a new metadata vdb, deploys using
the admin connection
6) Designer --> then using the Admin connection, retrieves the DDL using
"getSchema" method.
7) Designer --> builds model.
For (2) you will be developing a new MetadataFactory that understands the translator level
"getCatalog" kind methods. or modify the DDL Metadata Factory to do the same
with help of some flag. I thought using both JDBC and Admin interfaces for what looks like
single task for user prespective is not good. Other than that I do not have any other
objections
Provide hooks to interrogate metadata prior to full import
-----------------------------------------------------------
Key: TEIID-3429
URL:
https://issues.jboss.org/browse/TEIID-3429
Project: Teiid
Issue Type: Feature Request
Components: Server
Reporter: Steven Hawkins
Assignee: Steven Hawkins
To support the Desinger we should offer the ability to interrogate metadata prior to full
import.
Exploring metadata is effectively an entirely different mode of operation with respect to
the current metadata processing logic on the Teiid side. Also partial metadata isn't
something that would neatly be expressed through DDL - tables without columns, a list of
schema names, etc.
Ways around that would be to expose source procedures for metadata interrogation:
getTableNames - which would probably give both the Teiid name and the name in source and
consider the current translator metadata settings
getProcedureNames
And importer specific info such as for JDBC getTableTypes, getCatalogNames,
getSchemaNames
I'd want to keep it fairly high level though. Getting column or key information
I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)