[JBoss JIRA] (TEIID-3843) SAP HANA wrong results from MOD with float argument
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3843?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-3843:
------------------------------------
[~tejones], do you know an issue tracker for SAP HANA, where I could report the issue?
> SAP HANA wrong results from MOD with float argument
> ---------------------------------------------------
>
> Key: TEIID-3843
> URL: https://issues.jboss.org/browse/TEIID-3843
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.2.6_2
> Reporter: Jan Stastny
> Assignee: Ted Jones
>
> SAP HANA doesn't handle correctly MOD function with float arguments. The problem occurs when the float value is less than zero.
> According to SAP HANA documentation, its MOD implementation follows the symmetric handling of MOD on less than zero values. In such case, the resulting value should be computed as:
> a is negative whole number
> n is positive whole number
> mod(a,n)
> # get -1*a
> # compute mod(-1*a,n)
> # multiply the result by -1
> # result is -1*mod(-1*a,n)
> SAP HANA follows this rule for other numeric types than float. For example for Long value -24 MOD(-24,11)=-2 , which is correct according to the MOD definition.
> But when you call MOD(-24.0,11) you get 2.0
> In current state, the only thing Teiid could do is to prevent pushing MOD with float arguments. It helps to cast explicitly the column to double.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3841) sap-nw-gateway translator wrongly encodes when a parameter includes a space
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3841?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3841:
----------------------------------
Fix Version/s: 8.13
8.12.3
Affects Version/s: 8.7
The CXF webclient expects the address used to not include the query string as it currently does.
> sap-nw-gateway translator wrongly encodes when a parameter includes a space
> ---------------------------------------------------------------------------
>
> Key: TEIID-3841
> URL: https://issues.jboss.org/browse/TEIID-3841
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 8.13, 8.12.3
>
>
> Submitting a function through the sap-nw-gateway translator results in overzealous encoding of the URL when one of the parameters includes a space like "AA AB". The '?' character (along with the spaces in any parameters) in the expected URL [1] is encoded to '%3F' resulting in an error like [2] below.
> [1] https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/GetFl...'AA AB'&connectionid='0017'
> [2] org.teiid.runtime.client.TeiidClientException: java.lang.RuntimeException: Remote org.teiid.core.TeiidProcessingException: TEIID30504 flightdemo: TEIID17013 Wrong response from source with HTTP Response Code 404: Vendor Code "005056A509B11EE1B9A8FEC11C21D78E": With message "Resource not found for the segment 'GetFlightDetails%3Fairlineid='AA%20AB'&connectionid='0017''.": Detail Error null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3842?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3842:
---------------------------------------
> But in Teiid, we need use Teiid API, and need enable showplan in advance
Which is similar to SQL Server. You also don't need to use any JDBC / Java specific API by issuing a "SHOW PLAN" statement.
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
This would not be the same as a cache hint as it would be a new keyword - which should only be done at a major version since it can be a breaking change.
There are no standards here in terms of syntax or output, so there isn't really consistency that we necessarily should be targeting. Generally this feature for us has been more tooling rather than user oriented, so it's fine to try to update it in terms of what could be more helpful for users.
> The plan structure is too complex
Unfortunately a tree structure makes the most sense for anything beyond a simple query - as that conveys the exact processing layout and due to the optimization and rewrite process the user query symbols may not exist anymore so it could be hard to simply correlate back to the user query.
> Teiid's query's explain not consistence with other Database
> ------------------------------------------------------------
>
> Key: TEIID-3842
> URL: https://issues.jboss.org/browse/TEIID-3842
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.x
>
>
> h2. The way to get execution plan is not consistence with others
> For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
> {code}
> explain select ...
> {code}
> But in Teiid, we need use Teiid API, and need enable showplan in advance:
> {code}
> statement.execute("set showplan on");
> ResultSet rs = statement.executeQuery("select ...");
> TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
> PlanNode queryPlan = tstatement.getPlanDescription();
> System.out.println(queryPlan);
> {code}
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
> h2. The plan structure is too complex
> [1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
> [1] dynamicvdb-datafederation's 'select * from Stock' query plan
> {code}
> ProjectNode
> + Relational Node ID:0
> + Output Columns:
> 0: product_id (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: company_name (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:1
> + Output Columns:
> 0: ID (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 4
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:2
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 7
> 3: Node Cumulative Process Time: 7
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> ProjectNode
> + Relational Node ID:3
> + Output Columns:file (clob)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:
> 0: file (clob)
> 1: filePath (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:EXEC MarketData.getTextFiles('*.txt')
> + Model Name:MarketData
> + Select Columns:MarketData.getTextFiles.file
> + Child 1:
> TextTableNode
> + Relational Node ID:5
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 3
> 2: Node Cumulative Next Batch Process Time: 3
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
> + Join Strategy:NESTED TABLE JOIN
> + Join Type:CROSS JOIN
> + Join Criteria
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:
> 0: SYMBOL (string)
> 1: ID (integer)
> 2: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 25
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 17
> 4: Node Next Batch Calls: 5
> 5: Node Blocks: 4
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
> + Model Name:Accounts
> + Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
> + Join Type:INNER JOIN
> + Join Criteria:SP.symbol=A.SYMBOL
> + Select Columns:
> 0: A.ID AS product_id
> 1: SP.symbol
> 2: SP.price
> 3: A.COMPANY_NAME AS company_name
> + Data Bytes Sent:0
> + Planning Time:128
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3829) olingo module junit test failed
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3829?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3829:
---------------------------------------
It will be bulk merged along with the other 8.12.x fixes into 8.13 / master (and 9.0.x).
> olingo module junit test failed
> -------------------------------
>
> Key: TEIID-3829
> URL: https://issues.jboss.org/browse/TEIID-3829
> Project: Teiid
> Issue Type: Quality Risk
> Components: Build/Kits
> Affects Versions: 8.9
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 8.13, 8.12.3
>
>
> olingo module junit test failed:
> {code}
> Results :
> Failed tests:
> TestODataSQLBuilder.testEq:431->te:400->helpTest:227 expected:<...g0 WHERE g0.e1 = {t'[04]:20:02'} ORDER BY g0...> but was:<...g0 WHERE g0.e1 = {t'[16]:20:02'} ORDER BY g0...>
> TestODataSQLBuilder.testTimeMethods:552->te:400->helpTest:227 expected:<...YEAR({ts'2008-10-13 [04]:20:02.0'}) = 2008 O...> but was:<...YEAR({ts'2008-10-13 [16]:20:02.0'}) = 2008 O...>
> Tests run: 109, Failures: 2, Errors: 0, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3843) SAP HANA wrong results from MOD with float argument
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3843?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3843:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1284878
Bugzilla Update: Perform
> SAP HANA wrong results from MOD with float argument
> ---------------------------------------------------
>
> Key: TEIID-3843
> URL: https://issues.jboss.org/browse/TEIID-3843
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.2.6_2
> Reporter: Jan Stastny
> Assignee: Ted Jones
>
> SAP HANA doesn't handle correctly MOD function with float arguments. The problem occurs when the float value is less than zero.
> According to SAP HANA documentation, its MOD implementation follows the symmetric handling of MOD on less than zero values. In such case, the resulting value should be computed as:
> a is negative whole number
> n is positive whole number
> mod(a,n)
> # get -1*a
> # compute mod(-1*a,n)
> # multiply the result by -1
> # result is -1*mod(-1*a,n)
> SAP HANA follows this rule for other numeric types than float. For example for Long value -24 MOD(-24,11)=-2 , which is correct according to the MOD definition.
> But when you call MOD(-24.0,11) you get 2.0
> In current state, the only thing Teiid could do is to prevent pushing MOD with float arguments. It helps to cast explicitly the column to double.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3843) SAP HANA wrong results from MOD with float argument
by Jan Stastny (JIRA)
Jan Stastny created TEIID-3843:
----------------------------------
Summary: SAP HANA wrong results from MOD with float argument
Key: TEIID-3843
URL: https://issues.jboss.org/browse/TEIID-3843
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 8.7.2.6_2
Reporter: Jan Stastny
Assignee: Ted Jones
SAP HANA doesn't handle correctly MOD function with float arguments. The problem occurs when the float value is less than zero.
According to SAP HANA documentation, its MOD implementation follows the symmetric handling of MOD on less than zero values. In such case, the resulting value should be computed as:
a is negative whole number
n is positive whole number
mod(a,n)
# get -1*a
# compute mod(-1*a,n)
# multiply the result by -1
# result is -1*mod(-1*a,n)
SAP HANA follows this rule for other numeric types than float. For example for Long value -24 MOD(-24,11)=-2 , which is correct according to the MOD definition.
But when you call MOD(-24.0,11) you get 2.0
In current state, the only thing Teiid could do is to prevent pushing MOD with float arguments. It helps to cast explicitly the column to double.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3842?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3842:
------------------------------------
The following is a example of mysql query plan
{code}
MariaDB [products]> explain SELECT * FROM PRODUCT p INNER JOIN HOLDINGS h ON p.ID = h.PRODUCT_ID JOIN ACCOUNT a ON h.ACCOUNT_ID = a.ACCOUNT_ID;
+------+-------------+-------+--------+-----------------------+------------+---------+-----------------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+--------+-----------------------+------------+---------+-----------------------+------+-------------+
| 1 | SIMPLE | a | ALL | PRIMARY | NULL | NULL | NULL | 17 | |
| 1 | SIMPLE | h | ref | ACCOUNT_FK,PRODUCT_FK | ACCOUNT_FK | 5 | products.a.ACCOUNT_ID | 1 | Using where |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 4 | products.h.PRODUCT_ID | 1 | |
+------+-------------+-------+--------+-----------------------+------------+---------+-----------------------+------+-------------+
{code}
> Teiid's query's explain not consistence with other Database
> ------------------------------------------------------------
>
> Key: TEIID-3842
> URL: https://issues.jboss.org/browse/TEIID-3842
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.x
>
>
> h2. The way to get execution plan is not consistence with others
> For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
> {code}
> explain select ...
> {code}
> But in Teiid, we need use Teiid API, and need enable showplan in advance:
> {code}
> statement.execute("set showplan on");
> ResultSet rs = statement.executeQuery("select ...");
> TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
> PlanNode queryPlan = tstatement.getPlanDescription();
> System.out.println(queryPlan);
> {code}
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
> h2. The plan structure is too complex
> [1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
> [1] dynamicvdb-datafederation's 'select * from Stock' query plan
> {code}
> ProjectNode
> + Relational Node ID:0
> + Output Columns:
> 0: product_id (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: company_name (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:1
> + Output Columns:
> 0: ID (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 4
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:2
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 7
> 3: Node Cumulative Process Time: 7
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> ProjectNode
> + Relational Node ID:3
> + Output Columns:file (clob)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:
> 0: file (clob)
> 1: filePath (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:EXEC MarketData.getTextFiles('*.txt')
> + Model Name:MarketData
> + Select Columns:MarketData.getTextFiles.file
> + Child 1:
> TextTableNode
> + Relational Node ID:5
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 3
> 2: Node Cumulative Next Batch Process Time: 3
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
> + Join Strategy:NESTED TABLE JOIN
> + Join Type:CROSS JOIN
> + Join Criteria
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:
> 0: SYMBOL (string)
> 1: ID (integer)
> 2: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 25
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 17
> 4: Node Next Batch Calls: 5
> 5: Node Blocks: 4
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
> + Model Name:Accounts
> + Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
> + Join Type:INNER JOIN
> + Join Criteria:SP.symbol=A.SYMBOL
> + Select Columns:
> 0: A.ID AS product_id
> 1: SP.symbol
> 2: SP.price
> 3: A.COMPANY_NAME AS company_name
> + Data Bytes Sent:0
> + Planning Time:128
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months