February 2012 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1835) Querying a table built from WSDL Importer has no source query?

by Paul Nittel (Created) (JIRA)

Querying a table built from WSDL Importer has no source query? -------------------------------------------------------------- Key: TEIID-1835 URL: https://issues.jboss.org/browse/TEIID-1835 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.4.1 Environment: SOA-P 5.2 GA Reporter: Paul Nittel Assignee: Steven Hawkins I had previously deployed a Web service and figured I'd import the WSDL to make a relational model. The Designer process went well. The create procedure, called by: exec PartsWebXML.getSuppInfo.create_SuppInfo_Input('S106') generates a result <SuppInfo_Input xmlns="http://www.metamatrix.com/SuppInfo_Input"><SUPPLIER_ID>S106</SUPPLIER_ID></SuppInfo_Input> which goes into my query: exec PartsWebXML.getSuppInfo.extract_SuppInfo_output_Instance('<SuppInfo_Input xmlns="http://www.metamatrix.com/SuppInfo_Input"><SUPPLIER_ID>S106</SUPPLIER_ID></SuppInfo_Input>') The result set consists of zeros rows (only column headings). The query plan (attached) seems to be lacking a source query. The command log entries (also attached) support that theory, AFAICT. I'm also attaching the Model Project Set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
3
0 / 0

[JBoss JIRA] (TEIID-1797) When a message (i.e., WARN) is logged and its associated with a translator/connector, it would be nice to know to which one it applied

by Van Halbert (Created) (JIRA)

When a message (i.e., WARN) is logged and its associated with a translator/connector, it would be nice to know to which one it applied -------------------------------------------------------------------------------------------------------------------------------------- Key: TEIID-1797 URL: https://issues.jboss.org/browse/TEIID-1797 Project: Teiid Issue Type: Enhancement Components: LDAP Connector Affects Versions: 7.5 Reporter: Van Halbert Assignee: Steven Hawkins Priority: Minor Seeing the following warning when running a query: WARN [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue50) Search results exceeded size limit. Results may be incomplete There are 2 sources (jdbc and ldap) in the vdb, and not sure which one is causing the issue. Also, seeing this warning, I'm thinking I may not have all my results. What do I do or change in order to get all the results? Not sure what to do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
3
0 / 0

[JBoss JIRA] (TEIID-1811) Deleting a VDB from inventory does not remove it

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1811?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1811. --------------------------------- > Deleting a VDB from inventory does not remove it > ------------------------------------------------ > > Key: TEIID-1811 > URL: https://issues.jboss.org/browse/TEIID-1811 > Project: Teiid > Issue Type: Bug > Components: Tools > Affects Versions: 7.6 > Environment: JON 2.4.1/3.0.0, PostgreSQL 8.4.8, OpenJDK 1.6.0, SOA-P/EDS > 5.1.0/5.2.0 GA > Reporter: Pavel Kralik > Assignee: Ted Jones > > Using JON 2.4, deleting a VDB through JON GUI inventory removes the vdb from > the EDS instance, but does not remove it from inventory. Instead, it shows the > vdb as unavailable. > How reproducible: > Steps to Reproduce: > 1. Deploy a vdb to EDS > 2. Have agent report vdb to JON, verify in GUI > 3. In JON inventory, delete the vdb > Actual results: > VDB is removed from physical server but remains in JON inventory, just as > disabled. It remains there even after running 'discovery -f' from the agent > console. > Expected results: > VDB is removed from physical server and removed from JON inventory. > Additional info: > https://bugzilla.redhat.com/show_bug.cgi?id=739789 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-1796) Source Functions being pushed to the source are not taking into account NameInSource

by Paul Nittel (Created) (JIRA)

Source Functions being pushed to the source are not taking into account NameInSource ------------------------------------------------------------------------------------ Key: TEIID-1796 URL: https://issues.jboss.org/browse/TEIID-1796 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Paul Nittel Assignee: Steven Hawkins Attachments: PushDownTest_MPS.zip I imported BQT from Oracle, but did not import the SQUIRREL_GET_ERROR_OFFSET function. I then used the Source Function wizard to create the function. I named it RallySQUIRREL_GET_ERROR_OFFSET. When I executed the query, the function RallySQUIRREL_GET_ERROR_OFFSET was not found by Oracle. I had to rename the source function model to match the name of the function in Oracle. Shouldn't have to do that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
4
0 / 0

[JBoss JIRA] (TEIID-1856) Temp table becomes unusable by other threads

by Rick Wagner (Created) (JIRA)

Temp table becomes unusable by other threads -------------------------------------------- Key: TEIID-1856 URL: https://issues.jboss.org/browse/TEIID-1856 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.1 Reporter: Rick Wagner Assignee: Steven Hawkins Priority: Critical Fix For: 7.4.1, 7.6 If an update fails, the atomic rollback processing fails to properly unlock the write lock. Any other subsequent thread accessing the table would be locked out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1802) Async Event Processing: Translator callback indicating data is available

by Mark Addleman (Created) (JIRA)

Async Event Processing: Translator callback indicating data is available ------------------------------------------------------------------------- Key: TEIID-1802 URL: https://issues.jboss.org/browse/TEIID-1802 Project: Teiid Issue Type: Feature Request Reporter: Mark Addleman Assignee: Steven Hawkins In order to support more efficient streams of asynchronous events, the Execution Context should provide a callback from the translator to the engine to indicate that data is available. This semantics of this callback are analogous to the DataNotAvailableException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
3
0 / 0

[JBoss JIRA] (TEIID-1886) 7.6 api doc links to 7.5 javadoc

by Mark Addleman (Created) (JIRA)

7.6 api doc links to 7.5 javadoc -------------------------------- Key: TEIID-1886 URL: https://issues.jboss.org/browse/TEIID-1886 Project: Teiid Issue Type: Bug Components: Documentation Reporter: Mark Addleman Assignee: Steven Hawkins Priority: Minor The dropdown for the 7.6 api doc resolves to the 7.5 javadoc url -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1768) Temp table becomes unusable by other threads

by Steven Hawkins (Created) (JIRA)

Temp table becomes unusable by other threads -------------------------------------------- Key: TEIID-1768 URL: https://issues.jboss.org/browse/TEIID-1768 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical Fix For: 7.4.1, 7.6 If an update fails, the atomic rollback processing fails to properly unlock the write lock. Any other subsequent thread accessing the table would be locked out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1909) Teiid Salesforce Connector with date clause not returning correct data

by Graeme Gillies (JIRA)

Graeme Gillies created TEIID-1909: ------------------------------------- Summary: Teiid Salesforce Connector with date clause not returning correct data Key: TEIID-1909 URL: https://issues.jboss.org/browse/TEIID-1909 Project: Teiid Issue Type: Bug Components: Salesforce Connector Affects Versions: 7.5 Environment: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-1.23.1.9.10.el5_7-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) on Red Hat Enterprise Linux Server release 5.7 (Tikanga) Reporter: Graeme Gillies Assignee: Steven Hawkins Priority: Minor We have a user using the salesforce connector within teiid, and when they execute a query as follows {noformat} SELECT SFDC.salesforce.Case_.Origin ,SFDC.salesforce.Case_.CreatedDate ,SFDC.salesforce.Case_.CaseNumber FROM SFDC.salesforce.Case_ WHERE Product__c = 'Red Hat Enterprise Linux' AND CreatedDate >= '2009-03-01 00:00:00' AND CreatedDate < '2009-03-02 00:00:00' AND Origin IN ( 'Web' ,'Phone' ) order by createddate; {noformat} They get data like follows (casenumber removed) {noformat} origin | createddate | casenumber --------+-----------------------+------------ Web | 2009-03-01 06:10:12.0 | Web | 2009-03-01 09:47:35.0 | Web | 2009-03-01 09:55:45.0 | Web | 2009-03-01 10:04:07.0 | Web | 2009-03-01 10:25:06.0 | Web | 2009-03-01 11:20:18.0 | Web | 2009-03-01 11:25:11.0 | Web | 2009-03-01 13:23:36.0 | Web | 2009-03-01 13:43:22.0 | Phone | 2009-03-01 15:03:10.0 | Web | 2009-03-01 15:06:35.0 | Web | 2009-03-01 15:35:18.0 | Web | 2009-03-01 17:42:50.0 | Phone | 2009-03-01 18:15:42.0 | Phone | 2009-03-01 19:15:34.0 | Phone | 2009-03-01 19:44:43.0 | Web | 2009-03-01 20:09:12.0 | Web | 2009-03-01 20:25:24.0 | Web | 2009-03-01 20:38:08.0 | Web | 2009-03-01 22:50:45.0 | Web | 2009-03-01 23:32:53.0 | Web | 2009-03-01 23:58:01.0 | Web | 2009-03-02 00:11:43.0 | Web | 2009-03-02 00:30:52.0 | Web | 2009-03-02 00:35:19.0 | Web | 2009-03-02 00:37:49.0 | Web | 2009-03-02 00:44:57.0 | Web | 2009-03-02 01:21:17.0 | Web | 2009-03-02 01:24:20.0 | Phone | 2009-03-02 01:32:14.0 | Phone | 2009-03-02 01:54:19.0 | Phone | 2009-03-02 01:58:18.0 | Phone | 2009-03-02 02:17:56.0 | Web | 2009-03-02 02:32:55.0 | Phone | 2009-03-02 02:34:35.0 | Web | 2009-03-02 02:35:21.0 | Phone | 2009-03-02 02:37:16.0 | Phone | 2009-03-02 02:42:21.0 | Phone | 2009-03-02 02:46:03.0 | Phone | 2009-03-02 02:50:16.0 | Web | 2009-03-02 02:50:48.0 | Phone | 2009-03-02 02:54:29.0 | Phone | 2009-03-02 02:55:22.0 | Phone | 2009-03-02 02:57:11.0 | Phone | 2009-03-02 02:59:54.0 | Phone | 2009-03-02 03:00:54.0 | Phone | 2009-03-02 03:04:01.0 | Phone | 2009-03-02 03:06:38.0 | Phone | 2009-03-02 03:10:07.0 | Phone | 2009-03-02 03:12:11.0 | Phone | 2009-03-02 03:14:36.0 | Web | 2009-03-02 03:56:52.0 | Phone | 2009-03-02 04:07:16.0 | Web | 2009-03-02 04:12:25.0 | Web | 2009-03-02 04:19:47.0 | Web | 2009-03-02 04:27:17.0 | Web | 2009-03-02 04:36:03.0 | Web | 2009-03-02 04:36:10.0 | {noformat} As you can see, we are missing a bunch of data between 2009-03-01 00:00:00.0 and 2009-03-01 00:06:00.0 as well as getting data after 2009-03-02 00:00:00.0 which according to the where clause we shouldn't be getting. I'm assuming this is some sort of timezone conversion problem, but I'm not sure how to go about fixing it. Regards, Graeme -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] (TEIID-1881) With Teradata, querying XQT document fails with Failed to convert org.teiid.core.types.ClobType into java.lang.String

by Paul Nittel (Created) (JIRA)

With Teradata, querying XQT document fails with Failed to convert org.teiid.core.types.ClobType into java.lang.String --------------------------------------------------------------------------------------------------------------------- Key: TEIID-1881 URL: https://issues.jboss.org/browse/TEIID-1881 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.6 Reporter: Paul Nittel Assignee: Steven Hawkins Attachments: QT_teradata12_Push.vdb The query in question is: SELECT * FROM XQTDoc.BQTDocTestDocument. No form of convert appears to help. The underlying database is Teradata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

7
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2012