November 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5550) DISTINCT pushed down incorrectly in some cases

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5550?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5550. ----------------------------------- Fix Version/s: 11.1.2 12.0 11.2.1 Resolution: Done Updated the readability of the suspect logic and ensured that we don't look at dup removal nodes above a parent join. > DISTINCT pushed down incorrectly in some cases > ---------------------------------------------- > > Key: TEIID-5550 > URL: https://issues.jboss.org/browse/TEIID-5550 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.15.6_4 > Environment: JDV 6.4.5 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.1.2, 12.0, 11.2.1 > > > The parent DISTINCT is being removed over joins in particular situations. This is a regression from TEIID-3063 TEIID-3062. > Conditions: > - basic query structure is select distinct col from a join b on a.col2 = b.col2 > - a sort merge join variant must have been planned > - the sort must not be pushed to one of the children > - the projection related conditions of TEIID-3062 / TEIID-3063 must be met > - there is a one to many relationship > The result is that the parent distinct will be inappropriately removed, such that the output of the join can contain repetition of the col value when it should be distinct. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5550) DISTINCT pushed down incorrectly in some cases

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5550?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5550: ---------------------------------- Description: The parent DISTINCT is being removed over joins in particular situations. This is a regression from TEIID-3063 TEIID-3062. Conditions: - basic query structure is select distinct col from a join b on a.col2 = b.col2 - a sort merge join variant must have been planned - the sort must not be pushed to one of the children - the projection related conditions of TEIID-3062 / TEIID-3063 must be met - there is a one to many relationship The result is that the parent distinct will be inappropriately removed, such that the output of the join can contain repetition of the col value when it should be distinct. was: DISTINCT is pushing down to the wrong side of a JOIN (applies towards a different column than the user query). Adding an ORDER BY or GROUP BY to the query results in the query engine performing the dupremoval rather than pushing it down to a source. Should either not push the distinct down when performing federated join or push distinct down to the source that is relevant to the end user query. Example: SELECT DISTINCT nameValue FROM table1 Returns multiple rows as DISTINCT is pushed down (and to the source unrelated to nameValue) SELECT DISTINCT nameValue FROM table1 GROUP BY nameValue SELECT DISTINCT nameValue FROM table1 ORDER BY nameValue Returns expected results of 1 row in test > DISTINCT pushed down incorrectly in some cases > ---------------------------------------------- > > Key: TEIID-5550 > URL: https://issues.jboss.org/browse/TEIID-5550 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.15.6_4 > Environment: JDV 6.4.5 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Priority: Major > > The parent DISTINCT is being removed over joins in particular situations. This is a regression from TEIID-3063 TEIID-3062. > Conditions: > - basic query structure is select distinct col from a join b on a.col2 = b.col2 > - a sort merge join variant must have been planned > - the sort must not be pushed to one of the children > - the projection related conditions of TEIID-3062 / TEIID-3063 must be met > - there is a one to many relationship > The result is that the parent distinct will be inappropriately removed, such that the output of the join can contain repetition of the col value when it should be distinct. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5550) DISTINCT pushed down incorrectly in some cases

by Marc Shirley (Jira)

[ https://issues.jboss.org/browse/TEIID-5550?page=com.atlassian.jira.plugin... ] Marc Shirley updated TEIID-5550: -------------------------------- Description: DISTINCT is pushing down to the wrong side of a JOIN (applies towards a different column than the user query). Adding an ORDER BY or GROUP BY to the query results in the query engine performing the dupremoval rather than pushing it down to a source. Should either not push the distinct down when performing federated join or push distinct down to the source that is relevant to the end user query. Example: SELECT DISTINCT nameValue FROM table1 Returns multiple rows as DISTINCT is pushed down (and to the source unrelated to nameValue) SELECT DISTINCT nameValue FROM table1 GROUP BY nameValue SELECT DISTINCT nameValue FROM table1 ORDER BY nameValue Returns expected results of 1 row in test was: DISTINCT is pushing down to the wrong side of a JOIN (applies towards a different column than the user query). Adding an ORDER BY or GROUP BY to the query results in the query engine performing the dupremoval rather than pushing it down to a source. Should either not push it down when performing federated join or push down to the source relevant to the end user query. Example: SELECT DISTINCT nameValue FROM table1 Returns multiple rows as DISTINCT is pushed down (and to the source unrelated to nameValue) SELECT DISTINCT nameValue FROM table1 GROUP BY nameValue SELECT DISTINCT nameValue FROM table1 ORDER BY nameValue Returns expected results of 1 row in test > DISTINCT pushed down incorrectly in some cases > ---------------------------------------------- > > Key: TEIID-5550 > URL: https://issues.jboss.org/browse/TEIID-5550 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.15.6_4 > Environment: JDV 6.4.5 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Priority: Major > > DISTINCT is pushing down to the wrong side of a JOIN (applies towards a different column than the user query). Adding an ORDER BY or GROUP BY to the query results in the query engine performing the dupremoval rather than pushing it down to a source. Should either not push the distinct down when performing federated join or push distinct down to the source that is relevant to the end user query. > Example: > SELECT DISTINCT nameValue FROM table1 > Returns multiple rows as DISTINCT is pushed down (and to the source unrelated to nameValue) > SELECT DISTINCT nameValue FROM table1 GROUP BY nameValue > SELECT DISTINCT nameValue FROM table1 ORDER BY nameValue > Returns expected results of 1 row in test -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5545) Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header

by Christoph John (Jira)

[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ] Christoph John commented on TEIID-5545: --------------------------------------- Thanks for the info, in this case I will shift the decision into the future :) For development of my app the batch processing is not required. Hence I will first get things running and depending on the release state will decide later if I have to build a version myself. > Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header > -------------------------------------------------------------------------------------------------------- > > Key: TEIID-5545 > URL: https://issues.jboss.org/browse/TEIID-5545 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 11.2 > Reporter: Christoph John > Assignee: Ramesh Reddy > Priority: Critical > Fix For: 12.0 > > > When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in > https://developer.jboss.org/message/986421#986421 > It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request. > https://developer.jboss.org/message/986425#986425 > Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue: > https://github.com/SAP/openui5/issues/2288 > The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, > https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html > suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5509) Ensure compatibility with vert.x postgresql client

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5509?page=com.atlassian.jira.plugin... ] Work on TEIID-5509 started by Steven Hawkins. --------------------------------------------- > Ensure compatibility with vert.x postgresql client > -------------------------------------------------- > > Key: TEIID-5509 > URL: https://issues.jboss.org/browse/TEIID-5509 > Project: Teiid > Issue Type: Task > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > Vert.x has support for a async/reactive pg client. We should ensure that works with our pg protocol. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5530) common tables used in only 1 location which is a subquery still inlined

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5530?page=com.atlassian.jira.plugin... ] Work on TEIID-5530 started by Steven Hawkins. --------------------------------------------- > common tables used in only 1 location which is a subquery still inlined > ----------------------------------------------------------------------- > > Key: TEIID-5530 > URL: https://issues.jboss.org/browse/TEIID-5530 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > With a query such as: > with x as (select ...) > select (select ... from x where ...) from y > The x common table is inlined even though it may be less efficient for processing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5476) Teiid Embedded brings in JGroups dependency implicitly

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5476?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5476. ----------------------------------- Resolution: Done Resolved by moving jgroups related logic to jboss integration. The release notes and migration docs direct users to log an issue if they need a replicated embedded. We can discuss at that time the merits of creating a new module that could optionally pull that in for embedded. > Teiid Embedded brings in JGroups dependency implicitly > ------------------------------------------------------ > > Key: TEIID-5476 > URL: https://issues.jboss.org/browse/TEIID-5476 > Project: Teiid > Issue Type: Enhancement > Components: Embedded > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > Teiid Embedded brings in the JGroups dependency implicitly even when there is no clustering is required by the user. This adds about 2.5MB to the size. > Irrespective of the size, with the move to container kind of workloads, this should be enhanced such that it is an additional layer rather than part of the core layer. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5550) DISTINCT pushed down incorrectly in some cases

by Marc Shirley (Jira)

Marc Shirley created TEIID-5550: ----------------------------------- Summary: DISTINCT pushed down incorrectly in some cases Key: TEIID-5550 URL: https://issues.jboss.org/browse/TEIID-5550 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.12.15.6_4 Environment: JDV 6.4.5 Reporter: Marc Shirley Assignee: Steven Hawkins DISTINCT is pushing down to the wrong side of a JOIN (applies towards a different column than the user query). Adding an ORDER BY or GROUP BY to the query results in the query engine performing the dupremoval rather than pushing it down to a source. Should either not push it down when performing federated join or push down to the source relevant to the end user query. Example: SELECT DISTINCT nameValue FROM table1 Returns multiple rows as DISTINCT is pushed down (and to the source unrelated to nameValue) SELECT DISTINCT nameValue FROM table1 GROUP BY nameValue SELECT DISTINCT nameValue FROM table1 ORDER BY nameValue Returns expected results of 1 row in test -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5549) vdb-maven-plugin - FileNotFoundException when target directory doesn't exist

by G. Richard Bellamy (Jira)

[ https://issues.jboss.org/browse/TEIID-5549?page=com.atlassian.jira.plugin... ] G. Richard Bellamy commented on TEIID-5549: ------------------------------------------- PR: https://github.com/teiid/vdb-maven-plugin/pull/3 > vdb-maven-plugin - FileNotFoundException when target directory doesn't exist > ---------------------------------------------------------------------------- > > Key: TEIID-5549 > URL: https://issues.jboss.org/browse/TEIID-5549 > Project: Teiid > Issue Type: Bug > Components: Build/Kits, VDB > Affects Versions: 11.0.2 > Environment: {code} > 2018-11-21 07:29:39 > rbellamy@eanna i ~/Development/Terradatum/terradatum-data-virtualization master % java -version > openjdk version "1.8.0_192" > OpenJDK Runtime Environment (build 1.8.0_192-b26) > OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode) > 2018-11-21 07:29:44 > rbellamy@eanna i ~/Development/Terradatum/terradatum-data-virtualization master % mvn -v > Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00) > Maven home: /opt/maven > Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.19.2-arch1-1-arch", arch: "amd64", family: "unix" > {code} > Reporter: G. Richard Bellamy > Assignee: Barry LaFond > Priority: Major > > When building, if the {{target}} parent directory doesn't exist yet, the build will fail with a {{FileNotFoundException}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5549) vdb-maven-plugin - FileNotFoundException when target directory doesn't exist

by G. Richard Bellamy (Jira)

G. Richard Bellamy created TEIID-5549: ----------------------------------------- Summary: vdb-maven-plugin - FileNotFoundException when target directory doesn't exist Key: TEIID-5549 URL: https://issues.jboss.org/browse/TEIID-5549 Project: Teiid Issue Type: Bug Components: Build/Kits, VDB Affects Versions: 11.0.2 Environment: {code} 2018-11-21 07:29:39 rbellamy@eanna i ~/Development/Terradatum/terradatum-data-virtualization master % java -version openjdk version "1.8.0_192" OpenJDK Runtime Environment (build 1.8.0_192-b26) OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode) 2018-11-21 07:29:44 rbellamy@eanna i ~/Development/Terradatum/terradatum-data-virtualization master % mvn -v Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00) Maven home: /opt/maven Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.19.2-arch1-1-arch", arch: "amd64", family: "unix" {code} Reporter: G. Richard Bellamy Assignee: Barry LaFond When building, if the {{target}} parent directory doesn't exist yet, the build will fail with a {{FileNotFoundException}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues November 2018