July 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3563) Problems with capabilities initialization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3563?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3563. ----------------------------------- Resolution: Done Moved the getVersion call from the start method and made sure that we'll attempt to keep initializing the capabilities if there is a connection issue. > Problems with capabilities initialization > ----------------------------------------- > > Key: TEIID-3563 > URL: https://issues.jboss.org/browse/TEIID-3563 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.12, 8.11.1 > > > TEIID-3474 and somewhat TEIID-3483 introduced an issue with initializing capabilities. Postgresql effectively requires the database version set as a workaround. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3563) Problems with capabilities initialization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3563?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3563: ---------------------------------- Fix Version/s: 8.7.1.6_2 > Problems with capabilities initialization > ----------------------------------------- > > Key: TEIID-3563 > URL: https://issues.jboss.org/browse/TEIID-3563 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.12, 8.11.1 > > > TEIID-3474 and somewhat TEIID-3483 introduced an issue with initializing capabilities. Postgresql effectively requires the database version set as a workaround. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3563) Problems with capabilities initialization

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3563: ------------------------------------- Summary: Problems with capabilities initialization Key: TEIID-3563 URL: https://issues.jboss.org/browse/TEIID-3563 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 8.11 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.12, 8.11.1 TEIID-3474 and somewhat TEIID-3483 introduced an issue with initializing capabilities. Postgresql effectively requires the database version set as a workaround. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3562: --------------------------------------- > without timezone (GMT+1) - in this case no timezone has been set > 2. with timezone (GMT+5) - in this case timezone has been set by adding -Duser.timezone=GMT+5 to JAVA_OPTS (only for Teiid server) Please verify or explicitly set the timezone to be same across all vms/source to verify that the calendar fields stay the same. What client are you using with Teiid? As it will also matter what ResultSet.getTimestamp/getDate/getTime method is used. Just changing the server will mean that the client should adjust the calendar fields. For example ignoring Teradata if the server is in GMT-5 and there's a timestamp value with calendar fields "2001-01-01 13:00:00", then a client in GMT-1 using getTimestamp(col) will see the value "2001-01-01 09:00:00.0". If the client is in GMT-1 and uses getTimestamp(col, cal) where cal is in GMT, then they will see "2001-01-01 08:00:00.0" instead. > Teradata15 - teiid shifts date/time/timestamp values according to timezone. > --------------------------------------------------------------------------- > > Key: TEIID-3562 > URL: https://issues.jboss.org/browse/TEIID-3562 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.1.6_2 > Environment: teradata version - 15.00.01.01 > teradata driver version - 15.10.00.05 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > > Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3]. > [1] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+5 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0| > |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0| > |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0| > |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0| > |...|...|...|...| > [2] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+1 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0| > |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0| > |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0| > |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0| > |...|...|...|...| > [3] > *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1 > *local timezone:* GMT+1/GMT+5 > *Result:* > || c_0 || c_1 || c_2 || c_3 || > |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0| > |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0| > |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0| > |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0| > |...|...|...|...| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3490) WITH [TABLENAME] AS clause being sent to source query

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3490?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3490: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1224377|https://bugzilla.redhat.com/show_bug.cgi?id=1224377] from MODIFIED to ON_QA > WITH [TABLENAME] AS clause being sent to source query > ----------------------------------------------------- > > Key: TEIID-3490 > URL: https://issues.jboss.org/browse/TEIID-3490 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11, 8.7.4 > > > The transformation for that table is: > WITH MONTHEND AS (SELECT CONVERT(SQLBqt.tinya.DateValue, DATE) AS REFERENCE_VALUE FROM SQLBqt.tinya WHERE SQLBqt.tinya.IntKey = 2) > SELECT > RATES.INTKEY, MAX(CASE WHEN RATES.INTKEY = 20 THEN RATES.STRINGKEY END) AS GBP_RATE, MAX(CASE WHEN RATES.INTKEY = 25 THEN RATES.STRINGKEY END) AS EUR_RATE, MAX(CASE WHEN RATES.INTKEY = 30 THEN RATES.STRINGKEY END) AS USD_RATE > FROM > Oraclebqt.dssmalla2 AS RATES > WHERE > (RATES.INTKEY IN (20, 25, 30)) AND (RATES.DATEVALUE = (SELECT MONTHEND.REFERENCE_VALUE FROM MONTHEND)) > GROUP BY RATES.INTKEY > source queries are showing the With clause being pushed down to Oracle and they shouldn't be. > 11:11:54,283 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Vw26e70yOBmw.6.3.2 Processing NEW request: WITH MONTHEND (REFERENCE_VALUE) AS (SELECT CONVERT(g_0.DateValue, DATE) FROM SQLBqt.tinya AS g_0 WHERE g_0.IntKey = 2) SELECT g_0.INTKEY, MAX(CASE WHEN g_0.INTKEY = 20 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 25 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 30 THEN g_0.STRINGKEY END) FROM Oraclebqt.DSSMALLA2 AS g_0 WHERE (g_0.INTKEY IN (20, 25, 30)) AND (g_0.DATEVALUE = {d'2000-01-03'}) GROUP BY g_0.INTKEY > 11:11:54,283 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker3_QueryProcessorQueue30) Oraclebqt: getConnection(null, WrappedConnectionRequestInfo@2efc4e0e[userName=bqt2]) [0/20] > 11:11:54,283 INFO [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) OracleExecutionFactory Commit=true;DatabaseProductName=Oracle;DatabaseProductVersion=Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production > With the Partitioning, OLAP, Data Mining and Real Application Testing options;DriverMajorVersion=11;DriverMajorVersion=2;DriverName=Oracle JDBC driver;DriverVersion=11.2.0.1.0;IsolationLevel=2 > 11:11:54,283 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Vw26e70yOBmw.6.3.2 Obtained execution > 11:11:54,283 DEBUG [org.teiid.COMMAND_LOG] (Worker3_QueryProcessorQueue30) START DATA SRC COMMAND: startTime=2015-05-22 11:11:54.283 requestID=Vw26e70yOBmw.6 sourceCommandID=3 executionID=2 txID=null modelName=Oraclebqt translatorName=oracle sessionID=Vw26e70yOBmw principal=teiiduser@teiid-security sql=WITH MONTHEND (REFERENCE_VALUE) AS (SELECT CONVERT(g_0.DateValue, DATE) FROM SQLBqt.tinya AS g_0 WHERE g_0.IntKey = 2) SELECT g_0.INTKEY, MAX(CASE WHEN g_0.INTKEY = 20 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 25 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 30 THEN g_0.STRINGKEY END) FROM Oraclebqt.DSSMALLA2 AS g_0 WHERE (g_0.INTKEY IN (20, 25, 30)) AND (g_0.DATEVALUE = {d'2000-01-03'}) GROUP BY g_0.INTKEY > 11:11:54,285 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Source-specific command: WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY" > 11:11:54,285 TRACE [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Source sql WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY" > 11:11:55,514 DEBUG [org.teiid.COMMAND_LOG] (Worker3_QueryProcessorQueue30) ERROR SRC COMMAND: endTime=2015-05-22 11:11:55.514 requestID=Vw26e70yOBmw.6 sourceCommandID=3 executionID=2 txID=null modelName=Oraclebqt translatorName=oracle sessionID=Vw26e70yOBmw principal=teiiduser@teiid-security finalRowCount=null > 11:11:55,514 WARN [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Connector worker process failed for atomic-request=Vw26e70yOBmw.6.3.2: org.teiid.translator.jdbc.JDBCExecutionException: 907 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY"] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3358: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from MODIFIED to ON_QA > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11, 8.7.3 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3410) OData object URI does not resolve to a usable URL.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3410?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3410: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from MODIFIED to ON_QA > OData object URI does not resolve to a usable URL. > -------------------------------------------------- > > Key: TEIID-3410 > URL: https://issues.jboss.org/browse/TEIID-3410 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > OData object URI does not resolve to a usable URL. When accessing a VDB via odata with a browser either via JSON or XML the uri listed in the metadata is not valid, it doesn't have the FQN of the table, only the type shows FQN: > "__metadata" : { > "uri" : "http://localhost:8080/odata/ODataRHQ/rhq_agent(10001)", > "type" : "RHQ32.rhq_agent" -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3487) preparedstatement leaks in odbc

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3487?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3487: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1227330|https://bugzilla.redhat.com/show_bug.cgi?id=1227330] from MODIFIED to ON_QA > preparedstatement leaks in odbc > ------------------------------- > > Key: TEIID-3487 > URL: https://issues.jboss.org/browse/TEIID-3487 > Project: Teiid > Issue Type: Bug > Components: ODBC > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > There are several places where preparedstatements are being created and never closed by the odbc logic. And since we don't have garbage collection based cleanup, this can lead to a build up on the statementimpl. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3556) BufferManager reserve memory variable is decremented twice

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3556?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3556: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1234839|https://bugzilla.redhat.com/show_bug.cgi?id=1234839] from MODIFIED to ON_QA > BufferManager reserve memory variable is decremented twice > ---------------------------------------------------------- > > Key: TEIID-3556 > URL: https://issues.jboss.org/browse/TEIID-3556 > Project: Teiid > Issue Type: Bug > Components: Server > Reporter: Van Halbert > Assignee: Ramesh Reddy > Fix For: 8.7.1.6_2, 8.12, 8.11.1 > > > Web admin console shows negative value for Memory Used By Active Plans(KB) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3359) Allow more control over odata layer caching

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3359?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3359: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1227333|https://bugzilla.redhat.com/show_bug.cgi?id=1227333] from MODIFIED to ON_QA > Allow more control over odata layer caching > ------------------------------------------- > > Key: TEIID-3359 > URL: https://issues.jboss.org/browse/TEIID-3359 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11 > > > The caching is always performed at a user level and for each query. Consumers may need to localize the caching affect only to paging results and scope only to that interaction, rather than for all users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2015