teiid-issues November 2009

teiid-issues@lists.jboss.org

1 participants
174 discussions

[JBoss JIRA] Resolved: (TEIID-181) Allow connectors to request replanning of source query by throwing an exception

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-181?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-181. ---------------------------------- Resolution: Rejected Rejecting this form of the issue. Adding SQL-MED style planner conversations will be investigated later. > Allow connectors to request replanning of source query by throwing an exception > ------------------------------------------------------------------------------- > > Key: TEIID-181 > URL: https://jira.jboss.org/jira/browse/TEIID-181 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Reporter: Greg Haber > Assignee: Steven Hawkins > Priority: Minor > > In FEDERATE-126 more granular connector capabilities were requested, for supporting sources that don't follow traditional relational capability patterns (especially SFDC). > The level of effort for such a request is presumably fairly high for the DQP component, since it needs to have additional logic added to understand the new capability and to modify the planning process to take them into account. > It occurred to me that a general purpose backup mechanism would be for connectors to have the ability after getting a query they couldn't handle, to throw a new type of exception (perhaps ReplanRequestException), which would contain information about what connector capabilities should be excluded from the replanning process. Then the planner would come up with a new plan, and make new source query/queries based off that new plan. > For example take the case of SFDC, which handles outer joins (left or right, but not full) but not inner joins (and for the sake of argument say that FEDERATE-126 and FEDERATE-114 were not implemented). The SFDC connector gets sent a query with an inner join. It then throws an exception requesting a replan, this time with no join pushdown. Then the planner replans this as without join pushdown, and resubmits the query (or in many cases multiple queries). > Now, one big question here is, does replanning mean replanning the entire federated query, or just redoing that one source query? The former would give a more efficient overall plan, but it may be too late to do this (other connectors may already be at work). For the former to work, I would think we would need to have an additional step in the connector framework to run the proposed query plan by all the connectors before actually executing anything, which would be additional overhead on all queries, not the small subset for which this problem exists. So maybe the latter (redoing that one source query) is the only reasonable alternative. > A workaround with similar results is FEDERATE-114 style stuff (tell the consumer what was wrong, and ask them to override connector capabilities in a new query. But that has the same general inefficiency of an automatic replanning of the entire federated query. So it would not be as nice as replanning just one source query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Assigned: (TEIID-245) Update costing metadata at runtime

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-245?page=com.atlassian.jira.plug... ] Steven Hawkins reassigned TEIID-245: ------------------------------------ Assignee: Steven Hawkins > Update costing metadata at runtime > ---------------------------------- > > Key: TEIID-245 > URL: https://jira.jboss.org/jira/browse/TEIID-245 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #24584: Cost analysis should be both a design-time activity and scheduled/feed during runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-409) server port number should be checked for availability when creating a second mmprocess

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-409?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-409. ---------------------------------- Resolution: Out of Date The old server installation process no longer exists. > server port number should be checked for availability when creating a second mmprocess > -------------------------------------------------------------------------------------- > > Key: TEIID-409 > URL: https://jira.jboss.org/jira/browse/TEIID-409 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 7.x > Reporter: Marc Shirley > Fix For: 6.3 > > > Creating a second process on a server increments the port number by one from the primary process. This port number does not seem to be checked for availability, and so, if the second process's port is already in use, then status of the second process will be unreliable (it flickers between "Running" and "Not Started" states). One or more of the below actions should be taken: > 1) A check should be added to the process of adding a second process to detect whether a port is already in use. > 2) A KI entry should be made to cover the issue. > 3) Steps should be added to the Console User's Guide and/or Server Tuning Guide to advise the reader to make sure the port assigned to the second process is not in use by another application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-173) ProductAdmin role can deploy a vdb but cannot create connector bindings

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-173?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-173. ---------------------------------- Resolution: Deferred I'm inclined to just leave the existing produce admin vs. system admin distinction alone until we get more user feedback. My guess is that the product admin role is rarely used - and that connector bindings would have already been setup in an environment rendering this issue moot. > ProductAdmin role can deploy a vdb but cannot create connector bindings > ----------------------------------------------------------------------- > > Key: TEIID-173 > URL: https://jira.jboss.org/jira/browse/TEIID-173 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine, Server > Affects Versions: 7.x > Reporter: Steve Jacobs > Fix For: 6.3 > > > Defect Tracker #24544: Seems like if I have authorization to deploy a VDB, I should have authorization to create connector bindings. This should be re-evaluated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

← Newer
1
...
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues November 2009