May 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-219) Add a way to limit or suppress queries that exceed a threshold Cost-Based Optimizer value

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-219?page=com.atlassian.jira.plugin.... ] Steven Hawkins updated TEIID-219: --------------------------------- Fix Version/s: 10.x > Add a way to limit or suppress queries that exceed a threshold Cost-Based Optimizer value > ----------------------------------------------------------------------------------------- > > Key: TEIID-219 > URL: https://issues.jboss.org/browse/TEIID-219 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine, Server > Affects Versions: 6.0.0 > Reporter: Marc Shirley > Fix For: 10.x, 10.3 > > > Client requesting an ability to impose a limit on, or suppress, any query that exceeds a cost estimate value specified by the user/administrator. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4691) Consider replacing JGroups based custom replication with native

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4691?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4691: ---------------------------------- Fix Version/s: 10.x > Consider replacing JGroups based custom replication with native > --------------------------------------------------------------- > > Key: TEIID-4691 > URL: https://issues.jboss.org/browse/TEIID-4691 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Ramesh Reddy > Fix For: 10.x, 10.3 > > > JGroups is responsible for node to node communication. JGroups FRAG2 chunks up the messages that are sizeable by flow control. If you use TCP it will automatically break up the messages into the MTU. Using Jumbo Frames would be recommended. > Note that this will affect how we do the materialization replication among nodes currently. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2703) Refactor value retrieval to class based

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2703?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2703: ---------------------------------- Fix Version/s: 10.x > Refactor value retrieval to class based > --------------------------------------- > > Key: TEIID-2703 > URL: https://issues.jboss.org/browse/TEIID-2703 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.x, 10.3 > > > Similar to Hibernate, we need to introduce encapsulated value retrieval methods. The current approach (which is legacy back to the mmx days) typically uses a switch block with other checks, which can largely be avoided and should improve performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5337) Naming consistency issues with ddl vdbs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5337?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5337. ----------------------------------- Resolution: Done Did not yet address schema resolving order, but did make drop consistent with alter. The only thing left are functions, which are covered by TEIID-5338. > Naming consistency issues with ddl vdbs > --------------------------------------- > > Key: TEIID-5337 > URL: https://issues.jboss.org/browse/TEIID-5337 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.3 > > > Create is required to use a single part name as the parser and previous logic always assumed it took affect in the current schema. Alter is now allowed to generally resolve, but drop is not. Drop should probably be allowed to act against any schema. We should also consider having the current schema take resolving precedence with alter/drop. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4520: ------------------------------------- You need to look at the source query being generated by Teiid at translator layer. I suspect it is auto-translating the int to big decimal, or doing the filter after instead of pushdown. > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski edited comment on TEIID-4520 at 5/10/18 8:11 AM: ------------------------------------------------------------------- I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. If I remove ORDER BY it runs fine as well. A similar query but with merge on BigIntegerValue instead of BigDecimalValue: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type in the WHERE clause. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 was (Author: rkorytkowski): I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. If I remove ORDER BY it runs fine as well. A similar query by with merge on BigIntegerValue instead of BigDecimalValue: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type in the WHERE clause. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski edited comment on TEIID-4520 at 5/10/18 8:10 AM: ------------------------------------------------------------------- I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. If I remove ORDER BY it runs fine as well. A similar query by with merge on BigIntegerValue instead of BigDecimalValue: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type in the WHERE clause. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 was (Author: rkorytkowski): I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. A similar query: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type in the WHERE clause. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski edited comment on TEIID-4520 at 5/10/18 8:09 AM: ------------------------------------------------------------------- I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. A similar query: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type in the WHERE clause. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 was (Author: rkorytkowski): I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. A similar query: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski commented on TEIID-4520: ------------------------------------------ I've got one more intriguing issue. Executing: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigDecimalValue ORDER BY BQT1.SmallA.IntKey {code} results in: {noformat} Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. SQLState: 38000 ErrorCode: 0 {noformat} The same query runs just fine when I execute it against Exasol and not TEIID. A similar query: {code:sql} SELECT BQT1.SmallA.IntKey, BQT1.SmallB.BigDecimalValue FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntKey = BQT1.SmallB.BigIntegerValue ORDER BY BQT1.SmallA.IntKey {code} runs just fine in TEIID. It seems to have something to do with handling of the BigDecimal type. I'll continue investigating, but please let me know, if you have any clues. My current state of work is at https://github.com/teiid/teiid/compare/master...rkorytkowski:TEIID-4520 > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5338) Drop function drops all functions of the same name

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5338: ------------------------------------- Summary: Drop function drops all functions of the same name Key: TEIID-5338 URL: https://issues.jboss.org/browse/TEIID-5338 Project: Teiid Issue Type: Sub-task Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 10.3 Our create / drop function ddl support should allow for a unique name to reference functions by rather than removing all functions of a given name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 May 2018