January 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5197) Osisoft Translator - Wrong pushdown for DAYOFYEAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-5197?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-5197: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1530566 Bugzilla Update: Perform > Osisoft Translator - Wrong pushdown for DAYOFYEAR > ------------------------------------------------- > > Key: TEIID-5197 > URL: https://issues.jboss.org/browse/TEIID-5197 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver > Affects Versions: 8.12.x-6.4 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > > The DAYOFYEAR function is pushed to Osisoft PI as DAY, but that appears to actually return day of month (the documentation is not clear on this). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5198) Procedure names containing . do not resolve properly

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5198?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5198. ----------------------------------- Resolution: Done Changed the resolving logic to still look for partial matches even when a dot . is present in the name. > Procedure names containing . do not resolve properly > ---------------------------------------------------- > > Key: TEIID-5198 > URL: https://issues.jboss.org/browse/TEIID-5198 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.1, 9.3.6, 10.0.2 > > > It is allowable to create a procedure with . in the name: > CREATE FOREIGN PROCEDURE "my.proc" (param STRING) RETURNS TABLE (a INTEGER, b STRING); > However it can only be resolved as proc, not "my.proc" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5027) Translator infinispan-hotrod incorrect data type import

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5027?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5027: ---------------------------------- Fix Version/s: 9.3.6 > Translator infinispan-hotrod incorrect data type import > ------------------------------------------------------- > > Key: TEIID-5027 > URL: https://issues.jboss.org/browse/TEIID-5027 > Project: Teiid > Issue Type: Bug > Components: JDG Connector, Misc. Connectors > Affects Versions: 8.12.x-6.4 > Reporter: Jan Stastny > Assignee: Ramesh Reddy > Priority: Blocker > Fix For: 10.0, 8.12.x-6.4, 9.3.6 > > > I have a vdb: > {code:xml|title=jdg71_crud-vdb.xml} > <vdb name="jdg71_crud" version="1"> > <model name="Source" type="PHYSICAL" visible="true"> > <source name="jdg7-source" translator-name="infinispan-hotrod" connection-jndi-name="java:/jdg71HotrodDS" /> > <metadata type="DDL"><![CDATA[ > CREATE FOREIGN TABLE SmallA ( > IntKey integer, > IntNum integer, > DoubleNum double, > ObjectValue object, > BigDecimalValue bigdecimal, > BigIntegerValue biginteger, > CharValue char, > StringNum string, > StringKey string PRIMARY KEY, > FloatNum float, > LongNum long, > TimeValue time, > ShortValue short, > ByteNum byte, > TimeStampValue timestamp, > BooleanValue boolean, > DateValue date) OPTIONS(UPDATABLE true, "teiid_ispn:cache" '${jdg.cache.name}'); > ]]> > </metadata> > <metadata type = "NATIVE"/> > </model> > </vdb> > {code} > But the resulting metadata are: > || column_name | column_type || > || IntKey | integer || > || IntNum | integer || > || DoubleNum | double || > || ObjectValue | string || > || BigDecimalValue | varbinary || > || BigIntegerValue | varbinary || > || CharValue | string || > || StringNum | string || > || StringKey | string || > || FloatNum | float || > || LongNum | long || > || TimeValue | varbinary || > || ShortValue | integer || > || ByteNum | integer || > || TimeStampValue | varbinary || > || BooleanValue | boolean || > || DateValue | varbinary || > All the columns should be replaced by appropriate data type as defined in the vdb. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4977) Support materialization as the 8.12.x version did

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4977?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4977: ---------------------------------- Fix Version/s: 10.0 (was: 9.3.2) > Support materialization as the 8.12.x version did > ------------------------------------------------- > > Key: TEIID-4977 > URL: https://issues.jboss.org/browse/TEIID-4977 > Project: Teiid > Issue Type: Feature Request > Components: Infinispan, Quick Starts > Affects Versions: 8.12.x-6.4 > Reporter: Van Halbert > Assignee: Ramesh Reddy > Priority: Critical > Fix For: 10.0, 8.12.x-6.4 > > Attachments: ispn-vdb.xml, jdg-mat-cache-vdb.xml > > > Need to enable the materialization process to load the cache "offline" and not impact access to current cache and data. This would be similar to how the 8.12.x version was implemented and similar to how RDBMS materialization is done. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5165) Infinispan hotrod translator fails with growing size of returned data

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-5165?page=com.atlassian.jira.plugin... ] Van Halbert resolved TEIID-5165. -------------------------------- Resolution: Done > Infinispan hotrod translator fails with growing size of returned data > --------------------------------------------------------------------- > > Key: TEIID-5165 > URL: https://issues.jboss.org/browse/TEIID-5165 > Project: Teiid > Issue Type: Bug > Components: JDG Connector, Misc. Connectors > Affects Versions: 8.12.x-6.4 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > Fix For: 8.12.x-6.4, 10.x > > > Infinispan Hotrod translator fails depending on size of data returned. > I have a table with more than 5000 rows. > When I issue following query: > {code:sql} > SELECT IntKey FROM BQT1.LargeA WHERE Intkey<4095 > {code} > correct results are returned. > | 0 | > | 1 | > | ... | > | 4094 | > When I issue: > {code:sql} > SELECT IntKey FROM BQT1.LargeA WHERE Intkey<4096 > {code} > following exception occurs and no results are returned: > {code} > 12:27:56,933 ERROR [org.teiid.CONNECTOR] (Worker8_QueryProcessorQueue279) Connector worker process failed for atomic-request=+VUUR2vieWhT.59.0.46: java.util.NoSuchElementException > at java.util.ArrayList$Itr.next(ArrayList.java:860) [rt.jar:1.8.0_151] > at org.teiid.translator.infinispan.hotrod.InfinispanResponse.getNextRow(InfinispanResponse.java:106) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7] > at org.teiid.translator.infinispan.hotrod.InfinispanQueryExecution.next(InfinispanQueryExecution.java:142) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at sun.reflect.GeneratedMethodAccessor170.invoke(Unknown Source) [:1.8.0_151] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] > at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] > at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at com.sun.proxy.$Proxy79.more(Unknown Source) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_151] > at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151] > at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151] > 12:27:56,941 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue282) TEIID30020 Processing exception for request +VUUR2vieWhT.59 'TEIID30504 jdg7-source: null'. Originally TeiidProcessingException ArrayList.java:860. Enable more detailed logging to see the entire stacktrace. > {code} > Please note, that this is not affected only by number of rows, also by number of columns. So we're hitting a size limit on whole result set (influence of data type size has not been confirmed). > This affects also DELETE operation, as selection is part of the operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5198) Procedure names containing . do not resolve properly

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5198: ------------------------------------- Summary: Procedure names containing . do not resolve properly Key: TEIID-5198 URL: https://issues.jboss.org/browse/TEIID-5198 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 10.1, 9.3.6, 10.0.2 It is allowable to create a procedure with . in the name: CREATE FOREIGN PROCEDURE "my.proc" (param STRING) RETURNS TABLE (a INTEGER, b STRING); However it can only be resolved as proc, not "my.proc" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5190) Postgresql translator does not support expressions in group by

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5190?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5190. ----------------------------------- Resolution: Done Updated the capabilities for pg and h2. > Postgresql translator does not support expressions in group by > -------------------------------------------------------------- > > Key: TEIID-5190 > URL: https://issues.jboss.org/browse/TEIID-5190 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.1 > > > Inline views are being added in situations involving expressions in the group by clause because the translator is not marked as supporting that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5197) Osisoft Translator - Wrong pushdown for DAYOFYEAR

by Andrej Šmigala (JIRA)

Andrej Šmigala created TEIID-5197: ------------------------------------- Summary: Osisoft Translator - Wrong pushdown for DAYOFYEAR Key: TEIID-5197 URL: https://issues.jboss.org/browse/TEIID-5197 Project: Teiid Issue Type: Bug Components: JDBC Driver Affects Versions: 8.12.x-6.4 Reporter: Andrej Šmigala Assignee: Steven Hawkins The DAYOFYEAR function is pushed to Osisoft PI as DAY, but that appears to actually return day of month (the documentation is not clear on this). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5196) Osisoft Translator - Wrong data returned for some JOIN queries when integer and float columns are compared

by Andrej Šmigala (JIRA)

[ https://issues.jboss.org/browse/TEIID-5196?page=com.atlassian.jira.plugin... ] Andrej Šmigala updated TEIID-5196: ---------------------------------- Description: When using equality comparison between an integer and float columns in a WHERE or ON clause, Teiid pushes it to Osisoft PI with both columns cast as double. There seems to be a bug in Osisoft PI which causes the non-positive float values in the result for such a query to be returned as NULL (or not at all). E.g. {code:sql|title=Teiid query} SELECT BQT1.MediumA.IntNum, BQT1.MediumB.FloatNum FROM BQT1.MediumA FULL JOIN BQT1.MediumB ON BQT1.MediumA.IntNum = BQT1.MediumB.FloatNum WHERE BQT1.MediumA.IntNum >= -10 AND BQT1.MediumA.IntNum < 5 AND (BQT1.MediumB.FloatNum >= -10 AND BQT1.MediumB.FloatNum < 5) {code} is translated to {code:sql|title=Pushed Osisoft PI query} SELECT g_0.IntNum, g_1.FloatNum FROM dvqe..MediumA AS g_0, dvqe..MediumB AS g_1 WHERE cast(g_0.IntNum AS Double) = cast(g_1.FloatNum AS Double) AND g_0.IntNum < 5 AND g_1.FloatNum >= -10.0 AND g_1.FloatNum < 5.0 AND g_0.IntNum >= -10 {code} which seems to be correct, but returns the wrong result: ||IntNum||FloatNum|| |1|1| |2|2| |3|3| |4|4| Note that the only the positive values are returned, even though the criteria match also negative values (which are present in the source table). If the cast to double in the source query is removed (or replaced with cast to single), the query returns the expected results. was: When using equality comparison between an integer and float columns in a WHERE or ON clause, Teiid pushes it to Osisoft PI with both columns cast as double. There seems to be a bug in Osisoft PI which causes the non-positive float values in the result for such a query to be returned as NULL. E.g. {code:sql|title=Teiid query} SELECT BQT1.MediumA.IntNum, BQT1.MediumB.FloatNum FROM BQT1.MediumA FULL JOIN BQT1.MediumB ON BQT1.MediumA.IntNum = BQT1.MediumB.FloatNum WHERE BQT1.MediumA.IntNum >= -10 AND BQT1.MediumA.IntNum < 5 AND (BQT1.MediumB.FloatNum >= -10 AND BQT1.MediumB.FloatNum < 5) {code} is translated to {code:sql|title=Pushed Osisoft PI query} SELECT g_0.IntNum, g_1.FloatNum FROM dvqe..MediumA AS g_0, dvqe..MediumB AS g_1 WHERE cast(g_0.IntNum AS Double) = cast(g_1.FloatNum AS Double) AND g_0.IntNum < 5 AND g_1.FloatNum >= -10.0 AND g_1.FloatNum < 5.0 AND g_0.IntNum >= -10 {code} which seems to be correct, but returns the wrong result: ||IntNum||FloatNum|| |1|1| |2|2| |3|3| |4|4| Note that the only the positive values are returned, even though the criteria match also negative values (which are present in the source table). If the cast to double in the source query is removed (or replaced with cast to single), the query returns the expected results. > Osisoft Translator - Wrong data returned for some JOIN queries when integer and float columns are compared > ---------------------------------------------------------------------------------------------------------- > > Key: TEIID-5196 > URL: https://issues.jboss.org/browse/TEIID-5196 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.12.x-6.4 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > > When using equality comparison between an integer and float columns in a WHERE or ON clause, Teiid pushes it to Osisoft PI with both columns cast as double. > There seems to be a bug in Osisoft PI which causes the non-positive float values in the result for such a query to be returned as NULL (or not at all). > E.g. > {code:sql|title=Teiid query} > SELECT BQT1.MediumA.IntNum, BQT1.MediumB.FloatNum > FROM BQT1.MediumA > FULL JOIN BQT1.MediumB > ON BQT1.MediumA.IntNum = BQT1.MediumB.FloatNum > WHERE > BQT1.MediumA.IntNum >= -10 > AND BQT1.MediumA.IntNum < 5 > AND (BQT1.MediumB.FloatNum >= -10 > AND BQT1.MediumB.FloatNum < 5) > {code} > is translated to > {code:sql|title=Pushed Osisoft PI query} > SELECT g_0.IntNum, g_1.FloatNum > FROM dvqe..MediumA AS g_0, dvqe..MediumB AS g_1 > WHERE > cast(g_0.IntNum AS Double) = cast(g_1.FloatNum AS Double) > AND g_0.IntNum < 5 > AND g_1.FloatNum >= -10.0 > AND g_1.FloatNum < 5.0 > AND g_0.IntNum >= -10 > {code} > which seems to be correct, but returns the wrong result: > ||IntNum||FloatNum|| > |1|1| > |2|2| > |3|3| > |4|4| > Note that the only the positive values are returned, even though the criteria match also negative values (which are present in the source table). > If the cast to double in the source query is removed (or replaced with cast to single), the query returns the expected results. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5196) Osisoft Translator - Wrong data returned for some JOIN queries when integer and float columns are compared

by Andrej Šmigala (JIRA)

Andrej Šmigala created TEIID-5196: ------------------------------------- Summary: Osisoft Translator - Wrong data returned for some JOIN queries when integer and float columns are compared Key: TEIID-5196 URL: https://issues.jboss.org/browse/TEIID-5196 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 8.12.x-6.4 Reporter: Andrej Šmigala Assignee: Steven Hawkins When using equality comparison between an integer and float columns in a WHERE or ON clause, Teiid pushes it to Osisoft PI with both columns cast as double. There seems to be a bug in Osisoft PI which causes the non-positive float values in the result for such a query to be returned as NULL. E.g. {code:sql|title=Teiid query} SELECT BQT1.MediumA.IntNum, BQT1.MediumB.FloatNum FROM BQT1.MediumA FULL JOIN BQT1.MediumB ON BQT1.MediumA.IntNum = BQT1.MediumB.FloatNum WHERE BQT1.MediumA.IntNum >= -10 AND BQT1.MediumA.IntNum < 5 AND (BQT1.MediumB.FloatNum >= -10 AND BQT1.MediumB.FloatNum < 5) {code} is translated to {code:sql|title=Pushed Osisoft PI query} SELECT g_0.IntNum, g_1.FloatNum FROM dvqe..MediumA AS g_0, dvqe..MediumB AS g_1 WHERE cast(g_0.IntNum AS Double) = cast(g_1.FloatNum AS Double) AND g_0.IntNum < 5 AND g_1.FloatNum >= -10.0 AND g_1.FloatNum < 5.0 AND g_0.IntNum >= -10 {code} which seems to be correct, but returns the wrong result: ||IntNum||FloatNum|| |1|1| |2|2| |3|3| |4|4| Note that the only the positive values are returned, even though the criteria match also negative values (which are present in the source table). If the cast to double in the source query is removed (or replaced with cast to single), the query returns the expected results. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2018