[JBoss JIRA] (TEIID-2808) Oversights in parser test unit tests
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2808?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2808.
-----------------------------------
Resolution: Partially Completed
Marking as resolved as there have been no additional changes.
> Oversights in parser test unit tests
> ------------------------------------
>
> Key: TEIID-2808
> URL: https://issues.jboss.org/browse/TEIID-2808
> Project: Teiid
> Issue Type: Bug
> Components: Integration Tests
> Affects Versions: 8.4, 8.6
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
> Priority: Minor
> Attachments: 0001-TEIID-2808-Small-fixes-to-unit-tests-and-accompanyin.patch
>
>
> While integrating the unit tests from TestParser into Designer's teiid runtime client codebase, I found several small issues with the tests. All the tests pass in TestParser under Teiid hence these items have not necessarily been noticed and its a question of whether they should be.
> * testArrayTable
> ** The Constant node class' equals method does not test the 'type' field if the 'value' field is null. This allows the test to pass when the constants in the expected and actual Commands trees have different types. Discussion with [~rareddy] concluded the equals method does this by design.
> ** Suggestion is change the expected Constant to have NullType as its 'type' rather than Object.
> * testBlockExceptionHandling
> ** The Block node class has no equals method hence this test passes even though the 'groupExpression' field is different between expected and actual.
> * testDynamicCommand1
> ** The ElementSymbol node class never considers its 'type' field in its equals method hence the test passes despite an expected type of Integer against an actual type of null.
> ** test has a typo when the expected var 'a1' has its type set twice to String then Integer.
> * testStoredQuery2SanityCheck
> ** Has an extraneous query created and never used
> * testStoredQuerySubqueryMultipleParens
> ** Never executes due to a lack of @Test annotation. Judging by the comment it might be an experiment that has been commented out by removing the annotation. Reinforced by test failing with parsing exception.
> * testStoredQueryWithNoParameter2
> ** The test passes but has different expected and actual GroupSymbols in the From clause since the 'shortname' field is actually "x" rather than the expected "X". The reason is that GroupSymbol equals method does not test the 'shortname' field if the schema is null. This maybe by design?
> ** Suggestion is to at least change the expected value to "X".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3599) Excel translator and dynamic filenames
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3599?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-3599:
-------------------------------------
Fix Version/s: Open To Community
Assignee: (was: Steven Hawkins)
Putting into the open to community bucket. It should be straight-forward to allow some amount of wildcards or regex in this or a new property to allow the file name to change.
There is also file mapping setting that can be used on the file data source that allows for indirection in naming.
> Excel translator and dynamic filenames
> --------------------------------------
>
> Key: TEIID-3599
> URL: https://issues.jboss.org/browse/TEIID-3599
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ralph Martin Black
> Priority: Minor
> Fix For: Open To Community
>
>
> Hi all,
> All samples I've reached on how to setup a connection to xls files, set up file names as properties in the source model:
> ...
> <property name="importer.ExcelFileName" value="names.xls"/>
> ...
> Is there any way to specify filenames dynamically at run-time?
> Best regards
> MB!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-2132) Teiid 8.0 API does not expose boundport in Mbean attribute for Teiid-JDBC
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2132?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2132:
---------------------------------------
Can this be closed out Ramesh?
> Teiid 8.0 API does not expose boundport in Mbean attribute for Teiid-JDBC
> -------------------------------------------------------------------------
>
> Key: TEIID-2132
> URL: https://issues.jboss.org/browse/TEIID-2132
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Environment: jboss 7, teiid 8, windows 7
> Reporter: Akshay Harale
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: jboss, teiid
>
> When offset is set for jboss from standalone.xml or standalone.conf.bat file, the bound port is not displyed in MBean server.
>
> For example,
>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:25}">
>
> In above line if I set the value as 25 then that should be added to the default socket port values and exposed as bound port value in MBean server. But in case of teiid the "teiid-jdbc" 's boundPort value is not exposed by the jboss.
>
> All other boundPorts values are correctly shown in Mbean, except teiid-jdbc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-2742) transaction rollback in EDS with SQLServer
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2742?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2742.
-----------------------------------
Resolution: Out of Date
There have been no further updates on this in quite a while.
> transaction rollback in EDS with SQLServer
> ------------------------------------------
>
> Key: TEIID-2742
> URL: https://issues.jboss.org/browse/TEIID-2742
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Affects Versions: 7.7.8
> Environment: EDS 5.3.1
> Reporter: Hisanobu Okuda
> Assignee: Steven Hawkins
> Priority: Minor
>
> When using LoadTest within SoapUI, upon increase the number of threads to greater than 1, we encounter the ATOMIC transaction encountering roll back and the following error is found. However, when the threads only set to 1, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 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 updated TEIID-3748:
----------------------------------
Fix Version/s: 8.12.5
> 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: 9.0, 8.12.5, 8.13.1
>
> 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, 11 months
[JBoss JIRA] (TEIID-3947) Incorrect handling of text cells carrying pure numerals in Excel translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3947?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3947:
----------------------------------
Issue Type: Quality Risk (was: Bug)
> Incorrect handling of text cells carrying pure numerals in Excel translator
> ---------------------------------------------------------------------------
>
> Key: TEIID-3947
> URL: https://issues.jboss.org/browse/TEIID-3947
> Project: Teiid
> Issue Type: Quality Risk
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Steven Hawkins
> Priority: Minor
>
> When the user intends to retrieve (based on source model) textual data from a column in an Excel spreadsheet and when one or of the cells are pure numbers, what gets returned is the string representation of the double representation of the number.
> For example: If the cell has 1234, instead of returning 1234 Apache POI and DV returns 1234.0
> Adding more detail below from a Email sent as part of client update:
> After a thorough investigation into the issue it was found that JDV relies on Apache POI APIs to get the cell content . According to the link [1], Apache POI will return the cell type as double by default when asked for the cell type and when asked for the value will return the double value. JDV is doing its due diligence of converting the value to String [2] but by then POI has already returned 11.0 for a cell value of 11. And converting 11.0 to String will still keep it at
> 11.0.
> What should ideally happen, in my opinion is, the double should be compared against its Long equivalent and see if they are the same. If Yes, then the cell value should be extracted as string disregarding the type associated with the cell. This is because regardless of how you try to maintain a cell text value of 11.0, Excel always saves (don't confuse this with how it shows) it as 11.
> [1] https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html
> [2] https://goo.gl/nC3XoG
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3947) Incorrect handling of text cells carrying pure numerals in Excel translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3947?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3947:
----------------------------------
Component/s: Misc. Connectors
> Incorrect handling of text cells carrying pure numerals in Excel translator
> ---------------------------------------------------------------------------
>
> Key: TEIID-3947
> URL: https://issues.jboss.org/browse/TEIID-3947
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Steven Hawkins
> Priority: Minor
>
> When the user intends to retrieve (based on source model) textual data from a column in an Excel spreadsheet and when one or of the cells are pure numbers, what gets returned is the string representation of the double representation of the number.
> For example: If the cell has 1234, instead of returning 1234 Apache POI and DV returns 1234.0
> Adding more detail below from a Email sent as part of client update:
> After a thorough investigation into the issue it was found that JDV relies on Apache POI APIs to get the cell content . According to the link [1], Apache POI will return the cell type as double by default when asked for the cell type and when asked for the value will return the double value. JDV is doing its due diligence of converting the value to String [2] but by then POI has already returned 11.0 for a cell value of 11. And converting 11.0 to String will still keep it at
> 11.0.
> What should ideally happen, in my opinion is, the double should be compared against its Long equivalent and see if they are the same. If Yes, then the cell value should be extracted as string disregarding the type associated with the cell. This is because regardless of how you try to maintain a cell text value of 11.0, Excel always saves (don't confuse this with how it shows) it as 11.
> [1] https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html
> [2] https://goo.gl/nC3XoG
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3947) Incorrect handling of text cells carrying pure numerals in Excel translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3947?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3947.
-----------------------------------
Resolution: Done
Added a doc note for 9.0 about how to force the cell to a string representation.
> Incorrect handling of text cells carrying pure numerals in Excel translator
> ---------------------------------------------------------------------------
>
> Key: TEIID-3947
> URL: https://issues.jboss.org/browse/TEIID-3947
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Steven Hawkins
> Priority: Minor
>
> When the user intends to retrieve (based on source model) textual data from a column in an Excel spreadsheet and when one or of the cells are pure numbers, what gets returned is the string representation of the double representation of the number.
> For example: If the cell has 1234, instead of returning 1234 Apache POI and DV returns 1234.0
> Adding more detail below from a Email sent as part of client update:
> After a thorough investigation into the issue it was found that JDV relies on Apache POI APIs to get the cell content . According to the link [1], Apache POI will return the cell type as double by default when asked for the cell type and when asked for the value will return the double value. JDV is doing its due diligence of converting the value to String [2] but by then POI has already returned 11.0 for a cell value of 11. And converting 11.0 to String will still keep it at
> 11.0.
> What should ideally happen, in my opinion is, the double should be compared against its Long equivalent and see if they are the same. If Yes, then the cell value should be extracted as string disregarding the type associated with the cell. This is because regardless of how you try to maintain a cell text value of 11.0, Excel always saves (don't confuse this with how it shows) it as 11.
> [1] https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html
> [2] https://goo.gl/nC3XoG
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 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 resolved TEIID-3748.
-----------------------------------
Fix Version/s: 9.0
8.13.1
Resolution: Done
Updated the rewriter logic to also rewrite aggregate arguments - regardless of where they appear in the query.
> 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: 9.0, 8.13.1
>
> 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, 11 months