June 2010 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-947) UNION query with different datatypes on each side of UNION is producing inconsistent results

by Warren Gibson (JIRA)

UNION query with different datatypes on each side of UNION is producing inconsistent results --------------------------------------------------------------------------------------------- Key: TEIID-947 URL: https://jira.jboss.org/jira/browse/TEIID-947 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.0 Reporter: Warren Gibson Assignee: Steven Hawkins The following query is producing unexpected results in CTC. It is not consistent and sometimes produces unexpected results and sometimes passes. However, it can be reproduced. SELECT IntKey, IntNum FROM BQT1.SmallA UNION SELECT StringKey, StringNum FROM BQT2.MediumB ORDER BY IntKey The datatypes of each side of the union are not the same and sometimes rmdata.getColumnTypeName(++col) indicates its a string and sometimes it says its an integer. It is my understanding that the column should be implicitly converted to a consistent type (in this case a string). -- 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

14 years, 7 months

3
2
0 / 0

[JBoss JIRA] Created: (TEIID-1086) Possible missing I18N bundle for AdminShell

by Paul Nittel (JIRA)

Possible missing I18N bundle for AdminShell ------------------------------------------- Key: TEIID-1086 URL: https://jira.jboss.org/jira/browse/TEIID-1086 Project: Teiid Issue Type: Bug Environment: Teiid from May 5 build Reporter: Paul Nittel Assignee: Steven Hawkins This code excerpt println( "\nListing Connectors" ) aCon = getConnectorNames(); for (c in aCon) { println( " " + c ) println( " " + getConnectorPropertyDefinitions( c ) ) } produces output like this: Listing Connectors connector-salesforce-7.0.0-SNAPSHOT Exception thrown java.lang.ExceptionInInitializerError at org.teiid.adminapi.impl.PropertyDefinitionMetadata.toString(PropertyDefinitionMetadata.java:52) at TestAdmin.run(TestAdmin.groovy:54) at org.teiid.adminshell.GroovyAdminConsole$1$1.run(GroovyAdminConsole.java:55) Caused by: java.util.MissingResourceException: Can't find bundle for base name org.teiid.adminapi.impl.i18n, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1521) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1260) at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) at org.teiid.adminapi.impl.AdminPlugin.<clinit>(AdminPlugin.java:35) ... 3 more -- 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

14 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (TEIID-1047) Teiid host resultion should match that of the JBoss AS

by Ramesh Reddy (JIRA)

Teiid host resultion should match that of the JBoss AS ------------------------------------------------------ Key: TEIID-1047 URL: https://jira.jboss.org/jira/browse/TEIID-1047 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.0 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 7.0 Teiid "localhost" address resolution is done differently than that of the JBoss AS. JBoss AS always resolves to 127.0.0.1. The host resolution it self completely different between both; Teiid should mimic or reuse this from JBoss AS. -- 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

14 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (TEIID-891) Add JDBC import logic to correct unsigned types

by Steven Hawkins (JIRA)

Add JDBC import logic to correct unsigned types ----------------------------------------------- Key: TEIID-891 URL: https://jira.jboss.org/jira/browse/TEIID-891 Project: Teiid Issue Type: Feature Request Components: JDBC Connector Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 7.0 SQLServer/MySQL and other dbs have support for unsigned types. We should be able to import these types as a wider type to ensure that we can access the values. -- 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

14 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-803) The connector binding name assigned when created in the designer is not the name in the ConnectorBinding when using AdminAPI

by Van Halbert (JIRA)

The connector binding name assigned when created in the designer is not the name in the ConnectorBinding when using AdminAPI ---------------------------------------------------------------------------------------------------------------------------- Key: TEIID-803 URL: https://jira.jboss.org/jira/browse/TEIID-803 Project: Teiid Issue Type: Bug Components: AdminApi, Tools Affects Versions: 6.2.0 Reporter: Van Halbert Assignee: Steven Hawkins The name I assigned to the connectorbinding in the designer was "datasource1". I looked at the advanced properties and there is no other name property defined. Open the vdb file and view the Configuration.def file and it has the following: <Connector Name="datasource1" ComponentType="Loopback Connector" routingUUID="mmuuid:66dfa66b-4572-46ba-a477-8b6fe3895072"> <Properties> <Property Name="DeployedName">Transaction_1.datasource1</Property> </Properties> </Connector> When using the adminapi and calleding getName() on ConnectorBinding, the name returned is "Transaction_1.datasource1". The name that the user assignes to the binding should match the getName(). -- 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

14 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (TEIID-924) Remove metadataobjects

by Steven Hawkins (JIRA)

Remove metadataobjects ---------------------- Key: TEIID-924 URL: https://jira.jboss.org/jira/browse/TEIID-924 Project: Teiid Issue Type: Sub-task Components: Connector API Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.0 As long as we can rely on the querymetadatainterface being backed by our impls, then the use of the connector api metadataobjects becomes unnecessary. -- 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

14 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-927) Remove the legacy JDBC Datasource and Driver classes

by Ramesh Reddy (JIRA)

Remove the legacy JDBC Datasource and Driver classes ---------------------------------------------------- Key: TEIID-927 URL: https://jira.jboss.org/jira/browse/TEIID-927 Project: Teiid Issue Type: Task Components: JDBC Driver Reporter: Ramesh Reddy Fix For: 7.0 Delete EmbeddedDataSource EmbeddedDriver MMDriver MMDataSource classes from the JDBC library as Teiid already provides a replacement driver and data source since 6.2 release The replacement classes are TeiidDriver TeiidDataSource these will handle both server and embedded connections. -- 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

14 years, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (TEIID-1052) Replace beanshell based adminshell with Groovy

by Steven Hawkins (JIRA)

Replace beanshell based adminshell with Groovy ---------------------------------------------- Key: TEIID-1052 URL: https://jira.jboss.org/jira/browse/TEIID-1052 Project: Teiid Issue Type: Feature Request Components: AdminApi, Tools Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.0 After discussions on the mailing lists, it was determined that the contextual sql execution logic of the adminshell could be separated out, which paves the way for a simplified reimplementation of adminshell using Groovy. We will still need to determine what command line sql tool promote. -- 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

14 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-915) Error results in illegalstateexception

by Steven Hawkins (JIRA)

Error results in illegalstateexception -------------------------------------- Key: TEIID-915 URL: https://jira.jboss.org/jira/browse/TEIID-915 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.0 If results have already been sent and an exception occurs prior to the next batch request the result is an illegalstateexception. It would be better to just log that we aren't sending the exception to the client. Note that this only affects multi-batch non-transactional execution. In general there's no good way to ensure that the client will see the exception, since they aren't required to use the entire result set. -- 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

14 years, 7 months

2
2
0 / 0

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

by Steve Hawkins (JIRA)

[ https://jira.jboss.org/browse/TEIID-181?page=com.atlassian.jira.plugin.sy... ] Steve Hawkins closed TEIID-181. ------------------------------- > Allow connectors to request replanning of source query by throwing an exception > ------------------------------------------------------------------------------- > > Key: TEIID-181 > URL: https://jira.jboss.org/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/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2010