[JBoss JIRA] (TEIID-2981) Add an OData query parameter that caches the resultset
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2981?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-2981:
------------------------------------------------
Juraj Duráni <jdurani(a)redhat.com> changed the Status of [bug 1242029|https://bugzilla.redhat.com/show_bug.cgi?id=1242029] from ON_QA to VERIFIED
> Add an OData query parameter that caches the resultset
> ------------------------------------------------------
>
> Key: TEIID-2981
> URL: https://issues.jboss.org/browse/TEIID-2981
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Affects Versions: 8.7
> Reporter: John Muller
> Assignee: Steven Hawkins
> Priority: Minor
> Labels: Caching
> Fix For: 8.8, 8.7.5
>
>
> The Teiid caching guide indicates that the /*+ cache */ SQL hint is neccessary in order to cache results [1] . We would like two features added to the OData support: (1) to have a query parameter that basically injects the hint into the SQL statement run against the VDB and (2) a configuration setting that turns on OData resultset caching for all result sets smaller than some size (perhaps 256 as the default)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (TEIID-3625) JDG translator has disabled capabilities for GT and LT
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3625?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3625:
------------------------------------------------
David Le Sage <dlesage(a)redhat.com> changed the Status of [bug 1252914|https://bugzilla.redhat.com/show_bug.cgi?id=1252914] from ASSIGNED to CLOSED
> JDG translator has disabled capabilities for GT and LT
> ------------------------------------------------------
>
> Key: TEIID-3625
> URL: https://issues.jboss.org/browse/TEIID-3625
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Elias
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Operations GT and LT are not pushed down to JDG. Indexes are enabled for all columns. Operations GE and LE are pushed down correctly.
> Example:
> The first query is pushed down correctly. The second query doesn't push the "greater than" operator to the source.
> Query:
> {code}select intkey from smalla where intNum >= 5 order by intkey{code}
> PROCESSOR PLAN:
> {code}
> AccessNode(0) output=[c.intKey AS IntKey] SELECT g_0.intKey FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.intNum >= 5 ORDER BY g_0.intKey
> {code}
> Query:
> {code}select intkey from smalla where intNum > 5 order by intkey{code}
> Plan:
> {code}
> SortNode(0) output=[c.intKey AS IntKey] [SORT] [IntKey]
> ProjectNode(1) output=[c.intKey AS IntKey] [c.intKey AS IntKey]
> SelectNode(2) output=[c.intKey] c.intNum > 5
> AccessNode(3) output=[c.intNum, c.intKey] SELECT g_0.intNum, g_0.intKey FROM SmallAs.smallARemotecache AS g_0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[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.
-----------------------------------
Fix Version/s: 8.13
8.12.2
Resolution: Done
converted the offending hashmap to a treemap to maintain the ordering.
> 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.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, 6 months
[JBoss JIRA] (TEIID-3794) Impala Count Distinct with Case Statement Generates Bad SQL
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3794?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3794.
-----------------------------------
Resolution: Duplicate Issue
Same as TEIID-3748 - it has still not been determined what is introducing the else clauses.
> 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)
8 years, 6 months
[JBoss JIRA] (TEIID-3794) Impala Count Distinct with Case Statement Generates Bad SQL
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3794?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3794:
----------------------------------
Issue Type: Bug (was: Feature Request)
> Impala Count Distinct with Case Statement Generates Bad SQL
> -----------------------------------------------------------
>
> Key: TEIID-3794
> URL: https://issues.jboss.org/browse/TEIID-3794
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Scott Wallace
> Assignee: Steven Hawkins
>
> 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)
8 years, 6 months
[JBoss JIRA] (TEIID-3794) Impala Count Distinct with Case Statement Generates Bad SQL
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3794?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3794:
----------------------------------
Fix Version/s: (was: 8.12.x)
> 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
>
> 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)
8 years, 6 months
[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 commented on TEIID-3748:
---------------------------------------
This is not reproducible for me. There is no logic anywhere in the impala or general jdbc translator that will take the Teiid sql source query:
SELECT g_0.publisher_key, SUM(g_0.num_clicks), COUNT(DISTINCT CASE WHEN g_0.order_pub_comm_base >= 0 THEN g_0.orderid END) FROM fact_activity_advertiser_trans_date.fact_activity_advertiser_trans_date AS g_0 WHERE (g_0.trans_date_key >= '2015-09-01') AND (g_0.trans_date_key <= '2015-09-10') AND (g_0.advertiser_key = 2417) GROUP BY g_0.publisher_key HAVING (SUM(g_0.num_clicks) > 100) AND (COUNT(DISTINCT CASE WHEN g_0.order_pub_comm_base >= 0 THEN g_0.orderid END) = 0)
and insert the else clauses.
It would certainly appear that this and TEIID-3794 are due to a custom translator. Can you confirm if you are using the standard impala translator?
> 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)
8 years, 6 months
[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 reopened TEIID-3795:
-----------------------------------
There is an issue, which is dependent upon the jre implementation of hashmap. There should be an ordered map used instead.
> 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)
8 years, 6 months