[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> I am asking how you are also externalizing the access to these procedures?
All of the standard mechanisms would apply since they are nothing more than procedures. Are you thinking something special, such as specific exposure on the adminapi?
> BTW does SF provide any way interrogate metadata?
Not really that's why you'd only expose the getTables call, from there the user could include/exclude for the final import which will be more time consuming as it needs to pull all of the secondary metadata (keys, columns, etc.) - but that is much faster now in any case with TEIID-3455. The Hive translator would act similarly.
> 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)
9 years
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3429:
-------------------------------------
I am asking how you are also externalizing the access to these procedures? BTW does SF provide any way interrogate metadata?
> 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)
9 years
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> how are you thinking to expose these methods?
They are procedures exposed by the relevant translator.
> I am thinking the "getSchema" method can be designed to return different payload based on input parameter request, much like a odata request
You mean a general set if system procedures? I didn't that is the way to go as you still need a translator configured and it will need to be in a non-import mode. Also the set of procedures exposed by the different translators will be different.
> 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)
9 years
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3429:
-------------------------------------
how are you thinking to expose these methods? I am thinking the "getSchema" method can be designed to return different payload based on input parameter request, much like a odata request
> 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)
9 years
[JBoss JIRA] (TEIID-3452) Better highlighting in the query plan when an identified possible issue is seen
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3452?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3452:
-------------------------------------
priority seemed to be good option to have. May be when we design tools around it it would be easy to highlight
> Better highlighting in the query plan when an identified possible issue is seen
> -------------------------------------------------------------------------------
>
> Key: TEIID-3452
> URL: https://issues.jboss.org/browse/TEIID-3452
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.11
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> Looking a query plan that's printed in the server log, I see the following line:
> "LOW Relational Planner Negation is not supported by source People - People.Person.id < 2 was not pushed"
> Can the words "LOW Relational Planner Negation" be rephrased?
> The word "LOW" used in the context of the criteria not being pushed down would seem to me to be a possible CRITICAL issue to performance. And I'm not sure most users will claim to know what Relational Planner Negation means and what its implying on an error message.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (TEIID-3452) Better highlighting in the query plan when an identified possible issue is seen
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3452?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3452:
---------------------------------------
Are you ok with just a formatting change to the annotation lines:
priority [category] annotation - resolution
Or can suggest something else?
To add more context the notion of an annotation priority is localized.
High - it's not an error, but indicative that something is likely not correct. For example a hint that cannot be applied.
Medium - a major planning decision such as something around materialization, the use of document streaming for xquery, etc.
Low - almost a debug level statement of why a planning decision was made.
So something like criteria not being pushed is not necessarily an issue, just a planning decision. If the translator has no support, then that is the best that we can do.
If you are looking for a something more qualitative from a user perspective, that would be something new.
> Better highlighting in the query plan when an identified possible issue is seen
> -------------------------------------------------------------------------------
>
> Key: TEIID-3452
> URL: https://issues.jboss.org/browse/TEIID-3452
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.11
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> Looking a query plan that's printed in the server log, I see the following line:
> "LOW Relational Planner Negation is not supported by source People - People.Person.id < 2 was not pushed"
> Can the words "LOW Relational Planner Negation" be rephrased?
> The word "LOW" used in the context of the criteria not being pushed down would seem to me to be a possible CRITICAL issue to performance. And I'm not sure most users will claim to know what Relational Planner Negation means and what its implying on an error message.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years