June 2010 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-1136) MySql 50 OUTER JOIN - Unexpected Query Results

by Warren Gibson (JIRA)

MySql 50 OUTER JOIN - Unexpected Query Results ------------------------------------------------ Key: TEIID-1136 URL: https://jira.jboss.org/browse/TEIID-1136 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.1 Environment: Teiid 7.1 running query test suite MySql 5.0 Reporter: Warren Gibson Assignee: Steve Hawkins Receiving unexpected query results on the following query in MySQL 5.0: Query: SELECT BQT2.SmallA.IntNum, BQT2.MediumB.IntNum FROM BQT2.SmallA FULL OUTER JOIN BQT2.MediumB ON BQT2.SmallA.IntNum = BQT2.MediumB.IntNum ORDER BY BQT2.SmallA.IntNum, BQT2.MediumB.IntNum Database: jdbc:mysql://SLNTDS03.mm.atl2.redhat.com:3306/bqt2 Driver: mysql-connector-java-5.1.5 Expected results is 1007 records but MySQL is returning 1006. There are also some other issues. It appears (MediumB.IntNum = 26) is not being returned but it is expected and does exist in MediumB.IntNum. In addition one row is returning -21 when we expect -8 and many rows are returning "null" for MediumB.IntNum when we are expecting a value. I am attaching the log file, actual results file, expected results file, and the VDB. -- 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, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (TEIID-1129) Unable to execute SQL Queries through VDB's with more than one model in it from Designer/DTP

by Barry LaFond (JIRA)

Unable to execute SQL Queries through VDB's with more than one model in it from Designer/DTP -------------------------------------------------------------------------------------------- Key: TEIID-1129 URL: https://jira.jboss.org/browse/TEIID-1129 Project: Teiid Issue Type: Bug Affects Versions: 7.0 Reporter: Barry LaFond Assignee: Steve Hawkins Created VDB in Designer with 1 Source model in it (Partssupplier) and was able to submit basic "Select * from PARTS" and return results in DTP through Teiid "as JDBC source". Then 1) Undeployed VDB, 2) Created second Source model (Products) 3) Added Products source model to VDB 4) Made sure JNDI data sources were on Teiid server for both models 5) Deployed VDB containing both models 6) Able to query PARTS again 7) Unable to query "Select * from PRODUCTDATA" table. Error was: 14:25:38,705 WARN [PROCESSOR] Processing exception 'Group does not exist: PRODUCTDATA' for request uOko4PiAWqhG.0. Exception type org.teiid.api.exception.query.QueryResolverException thrown from org.teiid.query.resolver.util.ResolverUtil.handleUnresolvedGroup(ResolverUtil.java:853). Enable more detailed logging to see the entire stacktrace. -- 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, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (TEIID-896) INSERT failing with SF connector on types other than a string

by Mark Drilling (JIRA)

INSERT failing with SF connector on types other than a string ------------------------------------------------------------- Key: TEIID-896 URL: https://jira.jboss.org/jira/browse/TEIID-896 Project: Teiid Issue Type: Bug Components: Salesforce Connector Reporter: Mark Drilling Assignee: John Doyle I am attempting to do an INSERT into salesforce Account table, using the following INSERT INTO SFDC.salesforce.Account(IsDeleted, Name, Type, ParentId, BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry) VALUES ({b'false'},"MyTest","Customer","","123 Street","City","MO","66688","USA") The boolean type IsDeleted is causing failure with ClassCastException as follows: Caused by: java.lang.ClassCastException: java.lang.Boolean at com.metamatrix.connector.salesforce.execution.visitors.InsertVisitor.visit(InsertVisitor.java:44) at com.metamatrix.connector.salesforce.execution.InsertExecutionImpl.execute(InsertExecutionImpl.java:15) at com.metamatrix.connector.salesforce.execution.UpdateExecutionParent.execute(UpdateExecutionParent.java:67) at com.metamatrix.dqp.internal.datamgr.impl.ConnectorWorker.processNewRequest(ConnectorWorker.java:255) I have tried other types as well with the same result -- 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, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (TEIID-1118) Provide alternative webservices calling ability

by Steve Hawkins (JIRA)

Provide alternative webservices calling ability ----------------------------------------------- Key: TEIID-1118 URL: https://jira.jboss.org/browse/TEIID-1118 Project: Teiid Issue Type: Feature Request Components: Misc. Connectors, Query Engine, XML Connector Affects Versions: 7.0 Reporter: Steve Hawkins Assignee: Steve Hawkins Fix For: 7.0 With the xml/relational and combined source connector logic removed. There needs to be a replacement for web service access. -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (TEIID-673) Need to Document Alternate Means of Achieving Web Services and XML Usage Scenarios for Teiid

by Ted Jones (JIRA)

Need to Document Alternate Means of Achieving Web Services and XML Usage Scenarios for Teiid -------------------------------------------------------------------------------------------- Key: TEIID-673 URL: https://jira.jboss.org/jira/browse/TEIID-673 Project: Teiid Issue Type: Task Reporter: Ted Jones Assignee: Ted Jones For 6.2, we need to provide an alternative means to handle the current Web Services and XML Usage Scenarios for Teiid. These scenarios are captured as sub tasks of this task. Here is a link to the meeting notes regarding this subject: https://docspace.corp.redhat.com/clearspace/docs/DOC-21488 -- 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, 6 months

3
4
0 / 0

[JBoss JIRA] Closed: (TEIID-216) Query timeout should be enforced by the server

by Steve Hawkins (JIRA)

[ https://jira.jboss.org/browse/TEIID-216?page=com.atlassian.jira.plugin.sy... ] Steve Hawkins closed TEIID-216. ------------------------------- > Query timeout should be enforced by the server > ---------------------------------------------- > > Key: TEIID-216 > URL: https://jira.jboss.org/browse/TEIID-216 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #4990 : Query timeouts should be enforced by the server and client. > Also the RelationalNode nextbatch method will need to be made aware of the timeslice/timeout when handling 0 length batches. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1021) Enable better support for mixed database encoding

by Mark Drilling (JIRA)

Enable better support for mixed database encoding ------------------------------------------------- Key: TEIID-1021 URL: https://jira.jboss.org/jira/browse/TEIID-1021 Project: Teiid Issue Type: Feature Request Components: Server Reporter: Mark Drilling Assignee: Steven Hawkins I was working with a Japanese PostGreSQL database - database encoding is SQL_ASCII, but some of the columns have EUC_JP encoded data. I attempted to create a UDF to utilize the PostGreSQL convert(string, sourceEncoding, targetEncoding) function, but had difficulty with that (in the production version 554). Eventually we were able to workaround with other code changes, but handling of this situation may have been easier with a byte data type - logging this JIRA for consideration in teiid. -- 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, 6 months

3
5
0 / 0

[JBoss JIRA] Closed: (TEIID-966) User (principal) name in MetaMatrix should be consistently the same string

by Steve Hawkins (JIRA)

[ https://jira.jboss.org/browse/TEIID-966?page=com.atlassian.jira.plugin.sy... ] Steve Hawkins closed TEIID-966. ------------------------------- > User (principal) name in MetaMatrix should be consistently the same string > -------------------------------------------------------------------------- > > Key: TEIID-966 > URL: https://jira.jboss.org/browse/TEIID-966 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.0 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 7.0 > > > The issue has to do with the way we represent a user's name. Customer uses LDAP for a membership domain. Sometimes, the user's name is their cn, followed by "@" plus the domain name, e.g.: > username@LDAP > Sometimes, it's simply the user name. e.g.: > username > This name is recorded in the audit logs, used throughout Console, and perhaps most importantly, is the name returned by the USER() system function. > The problem is that we use the return value of USER() to record information about who is doing things. Later, we make comparisons against this info to control access, etc. This comparison often fails, even though we may be comparing the same identity, due to this inconsistency. > Workaround for the USER() function: build in special logic within each procedure to strip out the @LDAP if it is present. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-93) when a fairly complex query is pushed down to the XML-HTTP Connector, it fails

by Steve Hawkins (JIRA)

[ https://jira.jboss.org/browse/TEIID-93?page=com.atlassian.jira.plugin.sys... ] Steve Hawkins closed TEIID-93. ------------------------------ > when a fairly complex query is pushed down to the XML-HTTP Connector, it fails > ------------------------------------------------------------------------------ > > Key: TEIID-93 > URL: https://jira.jboss.org/browse/TEIID-93 > Project: Teiid > Issue Type: Bug > Components: XML Connector > Affects Versions: 8.x > Reporter: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #25059: when a fairly complex query is pushed down to the XML-HTTP > Connector, it fails > Need a lot more information. > OK, here's how to reproduce this issue (which we hit at Citi). Use the attached model project set in 5.5.1RC2 Designer, and use the response.xml attached with your standard xmltool.war tester. Then issue the following query from Designer: > >> > >> select H_RelationshipID, H_RelationshipName, H_HHID, H_TeamLeadName, H_TeamLeadID, H_MemberFirstName, H_MemberLastName, H_MemberAcctID, H_MemberFCName, H_MemberFCNum, H_HHLeadInd, H_MemberType, H_MemberRole, H_clientId, A_ADDR_TYPE, A_ADDR_SUB_TYPE, A_ADDR_SUB_NAME, A_ADDR_LINE1, A_ADDR_LINE2, A_ADDR_LINE3, A_ADDR_LINE4, A_ADDR_LINE5, A_ADDR_LINE6, A_ADDR_FLAG1, A_ADDR_FLAG2, A_ADDR_FLAG3, A_ADDR_FLAG4, A_ADDR_FLAG5, A_ADDR_FLAG6, A_CITY, A_ZIP, A_STATE_CODE, A_POSTAL_CODE, A_COUNTRY, A_ALTA_TYPE, A_EFF_DATE, A_EXP_DATE from "RPXMLTest"."CustRelnDataWS.WS.RetrieveCustRelnData.relnDataSingleTable" where A_ADDR_TYPE IN ('BA','AA') AND ((A_ADDR_TYPE IN('AA')) AND(NVL(A_ALTA_TYPE,'') = '')) > >> > >> This plans to the following source query being pushed to the connector: > >> > >> SELECT A_ALTA_TYPE, H_RelationshipID, H_RelationshipName, H_HHID, H_TeamLeadName, H_TeamLeadID, H_MemberFirstName, H_MemberLastName, H_MemberAcctID, H_MemberFCName, H_MemberFCNum, H_HHLeadInd, H_MemberType, H_MemberRole, H_clientId, A_ADDR_TYPE, A_ADDR_SUB_TYPE, A_ADDR_SUB_NAME, A_ADDR_LINE1, A_ADDR_LINE2, A_ADDR_LINE3, A_ADDR_LINE4, A_ADDR_LINE5, A_ADDR_LINE6, A_ADDR_FLAG1, A_ADDR_FLAG2, A_ADDR_FLAG3, A_ADDR_FLAG4, A_ADDR_FLAG5, A_ADDR_FLAG6, A_CITY, A_ZIP, A_STATE_CODE, A_POSTAL_CODE, A_COUNTRY, A_EFF_DATE, A_EXP_DATE FROM RPXMLTest.CustRelnDataWS.WS.RetrieveCustRelnData.relnDataSingleTable WHERE (A_ADDR_TYPE IN ('BA', 'AA')) AND (A_ADDR_TYPE = 'AA') > >> > >> Now, the criteria here says that A_ADDR_TYPE needs to be in the set of 'AA', 'BA', AND needs to be equal to 'AA'. So really only those "rows" where A_ADDR_TYPE='AA' should be returned. But instead the connector returns all rows where A_ADDR_TYPE is 'AA' or 'BA'. > >> > > > > This seems like it could be a defect in the way we hande IN criteria. Was there ever a case or defect on this? -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1040) Refine client control of query plans

by Steven Hawkins (JIRA)

Refine client control of query plans ------------------------------------ Key: TEIID-1040 URL: https://jira.jboss.org/jira/browse/TEIID-1040 Project: Teiid Issue Type: Feature Request Components: JDBC Driver, Query Engine Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.0 The OPTION clause settings DEBUG, SHOWPLAN and PLANONLY should be replaced with the following set statements: SET SHOWPLAN ON|DEBUG|OFF SET NOEXEC ON|OFF - general purpose way to turn off execution The plan will still be available off of the TeiidStatement JDBC extension. -- 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, 6 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2010