August 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4422) Impala Translator - add pushdown support for concat and concat_ws functions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4422?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4422: --------------------------------------- Our concat system function does currently push down to impala, but does not expect varargs - are you requesting that the Teiid system function supports varargs? Similarly are you requesting that a concat_ws system function be added? Or is it sufficient to just add concat_ws to the pushdown functions exposed by the translator? For group_concat, we can map that to the pushdown of the Teiid string_agg function. > Impala Translator - add pushdown support for concat and concat_ws functions > --------------------------------------------------------------------------- > > Key: TEIID-4422 > URL: https://issues.jboss.org/browse/TEIID-4422 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector > Affects Versions: 9.0.2 > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a consumer I need the concat and concat_ws function definitions with matching signatures in line with http://www.cloudera.com/documentation/archive/impala/2-x/2-0-x/topics/imp... > concat: > concat(string a, string b...) > Purpose: Returns a single string representing all the argument values joined together. > Return type: string > Usage notes: concat() and concat_ws() are appropriate for concatenating the values of multiple columns within the same row, while group_concat() joins together values from different rows. > concat_ws: > concat_ws(string sep, string a, string b...) > Purpose: Returns a single string representing the second and following argument values joined together, delimited by a specified separator. > Return type: string > Usage notes: concat() and concat_ws() are appropriate for concatenating the values of multiple columns within the same row, while group_concat() joins together values from different rows. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4422) Impala Translator - add pushdown support for concat and concat_ws functions

by Don Krapohl (JIRA)

Don Krapohl created TEIID-4422: ---------------------------------- Summary: Impala Translator - add pushdown support for concat and concat_ws functions Key: TEIID-4422 URL: https://issues.jboss.org/browse/TEIID-4422 Project: Teiid Issue Type: Feature Request Components: JDBC Connector Affects Versions: 9.0.2 Reporter: Don Krapohl Assignee: Steven Hawkins As a consumer I need the concat and concat_ws function definitions with matching signatures in line with http://www.cloudera.com/documentation/archive/impala/2-x/2-0-x/topics/imp... concat: concat(string a, string b...) Purpose: Returns a single string representing all the argument values joined together. Return type: string Usage notes: concat() and concat_ws() are appropriate for concatenating the values of multiple columns within the same row, while group_concat() joins together values from different rows. concat_ws: concat_ws(string sep, string a, string b...) Purpose: Returns a single string representing the second and following argument values joined together, delimited by a specified separator. Return type: string Usage notes: concat() and concat_ws() are appropriate for concatenating the values of multiple columns within the same row, while group_concat() joins together values from different rows. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4418) Pushdown of a correlated with clause contains wrong correlated reference

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4418?page=com.atlassian.jira.plugin... ] Work on TEIID-4418 started by Steven Hawkins. --------------------------------------------- > Pushdown of a correlated with clause contains wrong correlated reference > ------------------------------------------------------------------------ > > Key: TEIID-4418 > URL: https://issues.jboss.org/browse/TEIID-4418 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1 > > > A query such as: > {code} > select e1, e2 from pm1.g2 where e1 = (with CTE1 as /*+ no_inline */ (SELECT pm1.g2.e1 from pm1.g1) select e1 from CTE1) > {code} > will pushdown as: > {code} > SELECT g_0.e1, g_0.e2 FROM g2 AS g_0 WHERE g_0.e1 = (WITH CTE1 (e1) AS (SELECT g2.e1 AS expr1 FROM g1 AS g_0) SELECT g_1.e1 FROM CTE1 AS g_1) > {code} > Note the incorrect g2.e1 reference. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4323) Add support for first/last/absolute/relative "FETCH " syntax

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4323?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4323: ------------------------------------------------ Alex Szczuczko <aszczucz(a)redhat.com> changed the Status of [bug 1353933|https://bugzilla.redhat.com/show_bug.cgi?id=1353933] from MODIFIED to ON_QA > Add support for first/last/absolute/relative "FETCH " syntax > ------------------------------------------------------------ > > Key: TEIID-4323 > URL: https://issues.jboss.org/browse/TEIID-4323 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2, 8.12.6.6_3 > > > Add Support for the below FETCH syntax: > FETCH LAST FROM cursor_name > FETCH ABSOLUTE fetch_when FROM cursor_name > FETCH RELATIVE fetch_when FROM cursor_name > FETCH FIRST FROM cursor_name -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4411) With clauses in subqueries that appear in inline views should be pulled up

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4411?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4411: --------------------------------- Fix Version/s: 8.7.9.6_2 > With clauses in subqueries that appear in inline views should be pulled up > -------------------------------------------------------------------------- > > Key: TEIID-4411 > URL: https://issues.jboss.org/browse/TEIID-4411 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.9.6_2 > > > With clauses in subqueries that appear in inline views should be pulled up to the top level to avoid duplication and source issues with nested with clauses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4021) MSSQL Pagination

by Mark Tawk (JIRA)

[ https://issues.jboss.org/browse/TEIID-4021?page=com.atlassian.jira.plugin... ] Mark Tawk commented on TEIID-4021: ---------------------------------- The workaround you suggested is better then assigning the database version property on the executionfactory to the lowest version. New feature added : [Teiid Translator per source/version|https://issues.jboss.org/browse/TEIID-4421] > MSSQL Pagination > ---------------- > > Key: TEIID-4021 > URL: https://issues.jboss.org/browse/TEIID-4021 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Mark Tawk > Assignee: Steven Hawkins > Fix For: 9.1 > > > I'm using Teiid 8.11.3 with mssql translator. > I have a huge table over sql server 2008 on which i'm applying pagination. > I noticed slowliness in the query execution over this table at each time I increase the pagination. > I monitored the JDBC queries execute by teiid and found out that it is using top n according to the limit used into the query. > For example: > in teiid : Select * from mytable LIMIT 90 , 10 > is translated in JDBC: select top 100 from mytable > Since my table contains millions of records, when fetching the last page, the executed jdbc query is retrieving the whole table top n, to return in result the last 10 records. And the execution is taking too much time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4421) Teiid Translator per source/version

by Mark Tawk (JIRA)

Mark Tawk created TEIID-4421: -------------------------------- Summary: Teiid Translator per source/version Key: TEIID-4421 URL: https://issues.jboss.org/browse/TEIID-4421 Project: Teiid Issue Type: Feature Request Reporter: Mark Tawk Assignee: Steven Hawkins Teiid actually uses a single translator to connect to a single source/version. However in the case of translators that auto-configure to the given version it is expected to manage creating new instances when necessary. Case reproduced when connecting to 2 DBs, one on SQL Server 2012 and another on SQL Server 2008. The pagination SQL translation of SQL Server 2012 does not work on 2008. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4410) ConnectorWorkItem setting of convertIn should be based upon the execution factory

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4410?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4410: --------------------------------- Fix Version/s: 8.7.9.6_2 > ConnectorWorkItem setting of convertIn should be based upon the execution factory > --------------------------------------------------------------------------------- > > Key: TEIID-4410 > URL: https://issues.jboss.org/browse/TEIID-4410 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0, 8.12.5, 8.7.6.6_2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.9.6_2, 9.0.4 > > > TEIID-4112 introduced behavior that is allowing IN to be pushed when it should using OR. ConnectorWorkItem setting of convertIn should be based upon the execution factory not the capabilities object. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3795) Order of VARIADIC parameters is not preserved

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3795: --------------------------------- Fix Version/s: 8.7.9.6_2 > Order of VARIADIC parameters is not preserved > --------------------------------------------- > > Key: TEIID-3795 > URL: https://issues.jboss.org/browse/TEIID-3795 > Project: Teiid > Issue Type: Bug > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.12.2, 8.13, 8.7.9.6_2 > > > It seems that the order of VARIADIC arguments passed to a stored procedure is not always preserved. > For example, I defined a procedure in a virtual model in the VDB as follows: > {code:sql} > <model visible = "true" type = "VIRTUAL" name = "test_variadic"> > <metadata type = "DDL"><![CDATA[ > CREATE PROCEDURE p1(VARIADIC parameters string) > AS BEGIN > declare integer i = 1; > WHILE(i <= array_length(parameters)) > BEGIN > exec "SYSADMIN.logMsg"("level" => 'INFO', "context" => 'test', "msg" => 'param '|| parameters[i]); > i = i + 1; > END > END; > ]]> > </metadata> > </model> > {code} > The procedure just prints to the console the passed arguments. > When I call the procedure: > {code:sql} > exec "test_variadic.p1"('1' , '2', '3' , '4', '5' , '6', '7' , '8', '9' , '10', '11' , '12', '13' , '14', '15' , '16', '17' , '18', '19' , '20') > {code} > only the first 15 parameters are printed in the same order as they are passed, as shown in the log below: > {code} > 22:44:26,117 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 1 > 22:44:26,118 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 2 > 22:44:26,119 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 3 > 22:44:26,122 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 4 > 22:44:26,123 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 5 > 22:44:26,125 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 6 > 22:44:26,127 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 7 > 22:44:26,130 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 8 > 22:44:26,132 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 9 > 22:44:26,134 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 10 > 22:44:26,138 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 11 > 22:44:26,138 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 12 > 22:44:26,140 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 13 > 22:44:26,143 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 14 > 22:44:26,144 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 15 > 22:44:26,147 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 17 > 22:44:26,149 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 16 > 22:44:26,151 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 19 > 22:44:26,153 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 18 > 22:44:26,156 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 20 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3795) Order of VARIADIC parameters is not preserved

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-3795. -------------------------------- Resolution: Done > Order of VARIADIC parameters is not preserved > --------------------------------------------- > > Key: TEIID-3795 > URL: https://issues.jboss.org/browse/TEIID-3795 > Project: Teiid > Issue Type: Bug > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.7.9.6_2, 8.13, 8.12.2 > > > It seems that the order of VARIADIC arguments passed to a stored procedure is not always preserved. > For example, I defined a procedure in a virtual model in the VDB as follows: > {code:sql} > <model visible = "true" type = "VIRTUAL" name = "test_variadic"> > <metadata type = "DDL"><![CDATA[ > CREATE PROCEDURE p1(VARIADIC parameters string) > AS BEGIN > declare integer i = 1; > WHILE(i <= array_length(parameters)) > BEGIN > exec "SYSADMIN.logMsg"("level" => 'INFO', "context" => 'test', "msg" => 'param '|| parameters[i]); > i = i + 1; > END > END; > ]]> > </metadata> > </model> > {code} > The procedure just prints to the console the passed arguments. > When I call the procedure: > {code:sql} > exec "test_variadic.p1"('1' , '2', '3' , '4', '5' , '6', '7' , '8', '9' , '10', '11' , '12', '13' , '14', '15' , '16', '17' , '18', '19' , '20') > {code} > only the first 15 parameters are printed in the same order as they are passed, as shown in the log below: > {code} > 22:44:26,117 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 1 > 22:44:26,118 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 2 > 22:44:26,119 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 3 > 22:44:26,122 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 4 > 22:44:26,123 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 5 > 22:44:26,125 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 6 > 22:44:26,127 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 7 > 22:44:26,130 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 8 > 22:44:26,132 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 9 > 22:44:26,134 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 10 > 22:44:26,138 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 11 > 22:44:26,138 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 12 > 22:44:26,140 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 13 > 22:44:26,143 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 14 > 22:44:26,144 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 15 > 22:44:26,147 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 17 > 22:44:26,149 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 16 > 22:44:26,151 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 19 > 22:44:26,153 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 18 > 22:44:26,156 INFO [test] (Worker2_QueryProcessorQueue21) AbdPCQQAsiSL param 20 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2016