October 2015 - teiid-issues - Jboss List Archives

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

by Salvatore R (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Salvatore R commented on TEIID-3795: ------------------------------------ It seems that it doesn't depend on the logger. I accumulated the values and printed the result at the end in this way: {code:sql} CREATE PROCEDURE p1(VARIADIC parameters string) AS BEGIN declare integer i = 1; declare string result = ''; WHILE(i <= array_length(parameters)) BEGIN result = result || parameters[i] || ' '; i = i + 1; END exec "SYSADMIN.logMsg"("level" => 'INFO', "context" => 'test', "msg" => result); END; {code} but the order is still not preserved: 23:34:15,155 INFO [test] (Worker0_QueryProcessorQueue0) OkU8Fo/gqQZC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 19 18 20 > 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 > > 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)

9 years, 4 months

1
0
0 / 0

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

by Salvatore R (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Salvatore R edited comment on TEIID-3795 at 10/29/15 6:38 PM: -------------------------------------------------------------- It seems that it doesn't depend on the logger. I accumulated the values and printed the result at the end in this way: {code:sql} CREATE PROCEDURE p1(VARIADIC parameters string) AS BEGIN declare integer i = 1; declare string result = ''; WHILE(i <= array_length(parameters)) BEGIN result = result || parameters[i] || ' '; i = i + 1; END exec "SYSADMIN.logMsg"("level" => 'INFO', "context" => 'test', "msg" => result); END; {code} but the order is still not preserved: {code} 23:34:15,155 INFO [test] (Worker0_QueryProcessorQueue0) OkU8Fo/gqQZC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 19 18 20 {code} was (Author: fox123): It seems that it doesn't depend on the logger. I accumulated the values and printed the result at the end in this way: {code:sql} CREATE PROCEDURE p1(VARIADIC parameters string) AS BEGIN declare integer i = 1; declare string result = ''; WHILE(i <= array_length(parameters)) BEGIN result = result || parameters[i] || ' '; i = i + 1; END exec "SYSADMIN.logMsg"("level" => 'INFO', "context" => 'test', "msg" => result); END; {code} but the order is still not preserved: 23:34:15,155 INFO [test] (Worker0_QueryProcessorQueue0) OkU8Fo/gqQZC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 16 19 18 20 > 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 > > 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)

9 years, 4 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3795. ----------------------------------- Resolution: Rejected Presumably you are seeing the affects of an asynch logging appender. Try accumulating the value in the procedure to confirm that parameter order. > 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 > > 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)

9 years, 4 months

1
0
0 / 0

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

by Salvatore R (JIRA)

[ https://issues.jboss.org/browse/TEIID-3795?page=com.atlassian.jira.plugin... ] Salvatore R updated TEIID-3795: ------------------------------- Description: 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} was: 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, as shown in the log below, only the first 15 parameters are printed in the same order as they are passed: {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} > 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 > > 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)

9 years, 4 months

1
0
0 / 0

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

by Salvatore R (JIRA)

Salvatore R created TEIID-3795: ---------------------------------- Summary: 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 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, as shown in the log below, only the first 15 parameters are printed in the same order as they are passed: {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)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3794) Impala Count Distinct with Case Statement Generates Bad SQL

by Scott Wallace (JIRA)

Scott Wallace created TEIID-3794: ------------------------------------ Summary: Impala Count Distinct with Case Statement Generates Bad SQL Key: TEIID-3794 URL: https://issues.jboss.org/browse/TEIID-3794 Project: Teiid Issue Type: Feature Request Components: Misc. Connectors Affects Versions: 8.12 Reporter: Scott Wallace Assignee: Steven Hawkins Fix For: 8.12.x Executing a query like: {noformat} select count(distinct case when string_column='X' then bigint_column end) from some_vdb {noformat} Translates as the following in Impala: {noformat} SELECT COUNT(DISTINCT (CASE WHEN (`string_column` = 'X') THEN `bigint_column` ELSE CAST(NULL AS STRING) END)) as `EXPR_0` FROM `some_table` {noformat} Which fails with the following error: {noformat} AnalysisException: Incompatible return types 'BIGINT' and 'STRING' of exprs 'integer_column' and 'CAST(NULL AS STRING)'. {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3748) Impala translator - SELECT and HAVING statements are translating differently for Case statements

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3748?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3748: ---------------------------------- Fix Version/s: 8.12.2 > Impala translator - SELECT and HAVING statements are translating differently for Case statements > ------------------------------------------------------------------------------------------------ > > Key: TEIID-3748 > URL: https://issues.jboss.org/browse/TEIID-3748 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11.4 > Environment: Ubuntu Trusty > Reporter: Don Krapohl > Assignee: Steven Hawkins > Labels: Impala_Translator, Translators > Fix For: 8.12.2 > > Attachments: server.log > > > Error from Impala- > all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE CAST(NULL AS STRING) END)) > deviating function: count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE NULL END)) > Query: > SELECT user_key, sum(firstcol),count(distinct case when secondcol >= 0 then 1 end) > FROM sometable > WHERE customer_key=6 > GROUP BY user_key > HAVING sum(firstcol)>100 > AND count(distinct case when secondcol >= 0 then 1 end)=0 > > Query explanation: > For all users > Add up values in the firstcol column (integer column) > count distinct values in secondcol where secondcol value zero or more > otherwise return null (output is string) > Translated Teiid query: > SELECT user_key, SUM(firstcol) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE CAST(NULL AS STRING) END)) as `EXPR_1` > FROM sometable > WHERE customer_key` = 6 > HAVING (EXPR_0 > 100) AND (COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE NULL END)) = 0)) > Note the difference between the select and having for EXPR_1: > Select - THEN '1' ELSE CAST(NULL AS STRING) END > Having - THEN '1' ELSE NULL END > Impala doesn't accept that these are the same aggregate function. Aliases aren't accepted in the HAVING. > One further observation- if we swap the translation and write the statement in the select as > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE NULL END*)) > Teiid translates the SELECT to > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE CAST(NULL AS STRING) END*)) > So it always makes these mismatched. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3748) Impala translator - SELECT and HAVING statements are translating differently for Case statements

by Don Krapohl (JIRA)

[ https://issues.jboss.org/browse/TEIID-3748?page=com.atlassian.jira.plugin... ] Don Krapohl updated TEIID-3748: ------------------------------- Attachment: server.log > Impala translator - SELECT and HAVING statements are translating differently for Case statements > ------------------------------------------------------------------------------------------------ > > Key: TEIID-3748 > URL: https://issues.jboss.org/browse/TEIID-3748 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11.4 > Environment: Ubuntu Trusty > Reporter: Don Krapohl > Assignee: Steven Hawkins > Labels: Impala_Translator, Translators > Attachments: server.log > > > Error from Impala- > all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE CAST(NULL AS STRING) END)) > deviating function: count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE NULL END)) > Query: > SELECT user_key, sum(firstcol),count(distinct case when secondcol >= 0 then 1 end) > FROM sometable > WHERE customer_key=6 > GROUP BY user_key > HAVING sum(firstcol)>100 > AND count(distinct case when secondcol >= 0 then 1 end)=0 > > Query explanation: > For all users > Add up values in the firstcol column (integer column) > count distinct values in secondcol where secondcol value zero or more > otherwise return null (output is string) > Translated Teiid query: > SELECT user_key, SUM(firstcol) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE CAST(NULL AS STRING) END)) as `EXPR_1` > FROM sometable > WHERE customer_key` = 6 > HAVING (EXPR_0 > 100) AND (COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE NULL END)) = 0)) > Note the difference between the select and having for EXPR_1: > Select - THEN '1' ELSE CAST(NULL AS STRING) END > Having - THEN '1' ELSE NULL END > Impala doesn't accept that these are the same aggregate function. Aliases aren't accepted in the HAVING. > One further observation- if we swap the translation and write the statement in the select as > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE NULL END*)) > Teiid translates the SELECT to > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE CAST(NULL AS STRING) END*)) > So it always makes these mismatched. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3748) Impala translator - SELECT and HAVING statements are translating differently for Case statements

by Don Krapohl (JIRA)

[ https://issues.jboss.org/browse/TEIID-3748?page=com.atlassian.jira.plugin... ] Don Krapohl reopened TEIID-3748: -------------------------------- Adding log. Query executed: SELECT publisher_key,sum(num_clicks),count(distinct case when order_pub_comm_base >= 0 then orderid end) FROM ActivityAdvertiserTransDate WHERE trans_date_key BETWEEN '2015-09-01' AND '2015-09-10' AND advertiser_key=2417 GROUP BY publisher_key HAVING sum(num_clicks)>100 AND count(distinct case when order_pub_comm_base >= 0 then orderid end)=0 See exception at line 4297 Caused by: java.sql.SQLException: [Simba][ImpalaJDBCDriver](500051) ERROR processing query/statement. Error Code: 0, SQL state: TStatus(statusCode:ERROR_STATUS, sqlState:HY000, errorMessage:AnalysisException: all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (g_0.order_pub_comm_base >= 0) THEN g_0.orderid ELSE CAST(NULL AS STRING) END)); deviating function: count(DISTINCT (CASE WHEN (g_0.order_pub_comm_base >= 0) THEN g_0.orderid ELSE NULL END)) ), Query: SELECT `g_0`.`publisher_key`, SUM(ALL `g_0`.`num_clicks`) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (`g_0`.`order_pub_comm_base` >= 0) THEN `g_0`.`orderid` ELSE CAST(NULL AS STRING) END)) as `EXPR_1` FROM `mart`.`fact_activity_advertiser_trans_date` `g_0` WHERE ((`g_0`.`advertiser_key` = 2417) AND ((`g_0`.`trans_date_key` >= '2015-09-01') AND (`g_0`.`trans_date_key` <= '2015-09-10'))) GROUP BY `g_0`.`publisher_key` HAVING ((SUM(ALL `g_0`.`num_clicks`) > 100) AND (COUNT(DISTINCT (CASE WHEN (`g_0`.`order_pub_comm_base` >= 0) THEN `g_0`.`orderid` ELSE NULL END)) = 0)). > Impala translator - SELECT and HAVING statements are translating differently for Case statements > ------------------------------------------------------------------------------------------------ > > Key: TEIID-3748 > URL: https://issues.jboss.org/browse/TEIID-3748 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11.4 > Environment: Ubuntu Trusty > Reporter: Don Krapohl > Assignee: Steven Hawkins > Labels: Impala_Translator, Translators > > Error from Impala- > all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE CAST(NULL AS STRING) END)) > deviating function: count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE NULL END)) > Query: > SELECT user_key, sum(firstcol),count(distinct case when secondcol >= 0 then 1 end) > FROM sometable > WHERE customer_key=6 > GROUP BY user_key > HAVING sum(firstcol)>100 > AND count(distinct case when secondcol >= 0 then 1 end)=0 > > Query explanation: > For all users > Add up values in the firstcol column (integer column) > count distinct values in secondcol where secondcol value zero or more > otherwise return null (output is string) > Translated Teiid query: > SELECT user_key, SUM(firstcol) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE CAST(NULL AS STRING) END)) as `EXPR_1` > FROM sometable > WHERE customer_key` = 6 > HAVING (EXPR_0 > 100) AND (COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE NULL END)) = 0)) > Note the difference between the select and having for EXPR_1: > Select - THEN '1' ELSE CAST(NULL AS STRING) END > Having - THEN '1' ELSE NULL END > Impala doesn't accept that these are the same aggregate function. Aliases aren't accepted in the HAVING. > One further observation- if we swap the translation and write the statement in the select as > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE NULL END*)) > Teiid translates the SELECT to > COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE CAST(NULL AS STRING) END*)) > So it always makes these mismatched. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3581) Add a system function to return Teiid Server Name

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3581?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3581: ---------------------------------- Fix Version/s: 8.12.2 (was: 8.12.1) As a session property we'll have an issue if we ever move toward replicated sessions. It would be possible to retrieve via object table though. Pushing to 8.12.2 to get out 8.12.1 > Add a system function to return Teiid Server Name > ------------------------------------------------- > > Key: TEIID-3581 > URL: https://issues.jboss.org/browse/TEIID-3581 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Van Halbert > Fix For: 8.12.2 > > > A user has a 4 node Cluster and would like to get not only the sessionid, vdb and user but the node of the cluster that the user is connected to -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2015