[JBoss JIRA] (TEIID-2874) HIVE2: can't get the table list if using other than default database
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2874?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2874:
-------------------------------------
Looks like Hive driver ignores the setting of database at the end of the URL, and always connects to the "default"
After connection, I tried
{code}
use testing;
show tables
{code}
that worked! I will try to scrape the database name from URL and do the same.
> HIVE2: can't get the table list if using other than default database
> ---------------------------------------------------------------------
>
> Key: TEIID-2874
> URL: https://issues.jboss.org/browse/TEIID-2874
> Project: Teiid
> Issue Type: Bug
> Components: Connector API
> Affects Versions: 8.7
> Environment: Teiid with Hive2
> Reporter: Ivan Chan
> Assignee: Ramesh Reddy
> Labels: teiid
>
> I am not able to retrieve the table list other than default database.
> I have create a database other than default. And I named it as "Testing".
> And I put the database name in the URL:
> jdbc:hive2://machine_name:port/testing
> And it always returns a list of tables from default database. Nothing from "Testing" database
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2876) Order of DataTypeManager type names affects order of functions in FunctionLibrary
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2876?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2876.
-----------------------------------
Fix Version/s: 8.7
Resolution: Done
The bug here is that function ordering affects the resolver in an undersirable way. There isn't an issue for existing logic (brittleness aside, we do have a consistent ordering to type names / system functions), but the order of UDFs was not accounted for.
For now we have to leave the affect that the type names influence resolving (as it's used by other logic, such as determining common types). So there's a note now about the ordering of the type names mattering and a change to the determineNecessaryConversions to consider the most narrow function (based upon parameter order) over a function with the same number of conversions - I'm not really a fan of the "fewest conversions" logic, but we've left it basically intact as the primary argument type resolver for some time. We're also likely much too lenient in many circumstances.
There's no attempt to order the functions in the function tree though.
> Order of DataTypeManager type names affects order of functions in FunctionLibrary
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2876
> URL: https://issues.jboss.org/browse/TEIID-2876
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7, 8.4, 8.7
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.7
>
>
> This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
> Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
> {code}
> java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
> {code}
> The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
> Tracing this back showed the following:
> # In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
> # The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
> # The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
> The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
> Suggestions:
> * Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
> * Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
> * Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2873) VDB re-deploy issue with VDB that auto-generates REST wars
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2873?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-2873.
---------------------------------
Labels: Beta2 (was: )
Resolution: Done
There is timing issue when VDB is deployed in force REPLACE. This error does occur if normal UNDEPLOY and DEPLOY cycle. In the case of REPLACE, the both undeploy of the WAR/re-deploy WAR are met with timing issues as both processes are Async. Added code to schedule deployment of the WAR instead of error out in this situation.
> VDB re-deploy issue with VDB that auto-generates REST wars
> ----------------------------------------------------------
>
> Key: TEIID-2873
> URL: https://issues.jboss.org/browse/TEIID-2873
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
> Labels: Beta2
> Fix For: 8.7
>
> Attachments: ServerLog.txt
>
>
> I've encountered an issue when re-deploying a VDB that auto-generates and deploys REST wars. On re-deploy of the VDB, the REST wars don't always get deployed.
> Steps to reproduce and server.log is attached.
> Note this is on deploy of the VDB over an existing deployment. Workaround would be to explicitly un-deploy the VDB before doing the deploy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2872) Assertion failed error when joining multiple native queries.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2872?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2872.
-----------------------------------
Resolution: Duplicate Issue
This appears to be the same as TEIID-2707. As I cannot reproduce a similar scenario to this one in master with the fix (and the situation/exception is the same as the original issue).
> Assertion failed error when joining multiple native queries.
> ------------------------------------------------------------
>
> Key: TEIID-2872
> URL: https://issues.jboss.org/browse/TEIID-2872
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.5
> Environment: Windows 2003 server, Windows 7
> Reporter: SHI HONG CHIN
> Assignee: Steven Hawkins
> Attachments: JakkerData-vdb.xml, sql4.sql
>
>
> If I join multiple native queries, the following error occurred:
> 11:24:16,553 ERROR [org.teiid.PROCESSOR] (Worker21_QueryProcessorQueue534) ePitQkul9Wn5 TEIID30019 Unexpected exception for request ePitQkul9Wn5.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:287) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:63) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:190) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SourceState.sort(SourceState.java:315) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.MergeJoinStrategy.loadRight(MergeJoinStrategy.java:359) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadRight(EnhancedSortMergeJoinStrategy.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:208) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:155) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2876) Order of DataTypeManager type names affects order of functions in FunctionLibrary
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2876?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2876:
---------------------------------------
Yes, this does generally highlight a soft spot in the resolving logic, but I don't think we should enforce a preference for string over object. In this particular case it should be the latter as automatically widening to string is generally undesirable outside of string functions. I would gather that many other dbs would simply throw a resolving error in this case - especially if they lack and object/variant type.
I'll address this and remove the ambiguity.
> Order of DataTypeManager type names affects order of functions in FunctionLibrary
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2876
> URL: https://issues.jboss.org/browse/TEIID-2876
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7, 8.4, 8.7
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
> Priority: Minor
>
> This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
> Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
> {code}
> java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
> {code}
> The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
> Tracing this back showed the following:
> # In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
> # The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
> # The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
> The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
> Suggestions:
> * Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
> * Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
> * Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2875) Metadata failed to load. No column found
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2875?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2875:
---------------------------------------
Ramesh, how are you able to determine that this is happening when an index is loaded?
importApproximateIndexes is not new, and you should rarely need to set it to false. If false, then you are telling the db to use non-statistical methods to determine any applicable row counts for the index info - which could turn out to be quite expensive or in this case seems to be causing a privilege issue.
The simplest fix here is to determine if you need the RATE table. If not then you can add an exclusion for it.
To resolve this in general, as Ramesh is getting, we need to know when we're referencing this column (during index import, key import, etc.) which could be determined by shutting off individual imports or from the full stack trace. And we would need to see why it's not appearing in the primary table metadata.
> Metadata failed to load. No column found
> ----------------------------------------
>
> Key: TEIID-2875
> URL: https://issues.jboss.org/browse/TEIID-2875
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.6
> Environment: Windows server 2003, Windows 7.
> Reporter: SHI HONG CHIN
> Assignee: Steven Hawkins
> Attachments: JakkerData-vdb.xml
>
>
> Affected database: Oracle
> The following error displayed when Teiid loading a dynamic VDB:
> 10:21:41,458 WARN [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50036 VDB JakkerData.1 model "IWMS" metadata failed to load. Reason:TEIID60011 No column found with name "RATE"."CHARGE_NAME"
> 10:23:29,994 WARN [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50036 VDB JakkerData.1 model "IWMS" metadata failed to load. Reason:TEIID60011 No column found with name "RATE"."CHARGE_NAME"
> I am not the one who design the database. But, I cannot find any table with above mentioned column name in Oracle database. So, I am not sure whether the above mentioned column name is a hidden column or not.
> This bug does not exist in version 8.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2876) Order of DataTypeManager type names affects order of functions in FunctionLibrary
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/TEIID-2876?page=com.atlassian.jira.plugin... ]
Paul Richardson updated TEIID-2876:
-----------------------------------
Description:
This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
{code}
java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
{code}
The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
Tracing this back showed the following:
# In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
# The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
# The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
Suggestions:
* Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
* Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
* Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
was:
This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
<code>
java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
<code>
The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
Tracing this back showed the following:
1. In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
2. The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
3. The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
Suggestions:
* Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
* Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
* Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
> Order of DataTypeManager type names affects order of functions in FunctionLibrary
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2876
> URL: https://issues.jboss.org/browse/TEIID-2876
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7, 8.4, 8.7
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
> Priority: Minor
>
> This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
> Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
> {code}
> java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
> {code}
> The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
> Tracing this back showed the following:
> # In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
> # The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
> # The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
> The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
> Suggestions:
> * Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
> * Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
> * Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (TEIID-2876) Order of DataTypeManager type names affects order of functions in FunctionLibrary
by Paul Richardson (JIRA)
Paul Richardson created TEIID-2876:
--------------------------------------
Summary: Order of DataTypeManager type names affects order of functions in FunctionLibrary
Key: TEIID-2876
URL: https://issues.jboss.org/browse/TEIID-2876
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.4, 7.7, 8.7
Reporter: Paul Richardson
Assignee: Steven Hawkins
Priority: Minor
This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
<code>
java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
<code>
The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
Tracing this back showed the following:
1. In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
2. The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
3. The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
Suggestions:
* Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
* Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
* Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months