January 2014 - teiid-issues - Jboss List Archives

[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 commented on TEIID-2808: --------------------------------------- Applied the patch with additional changes. We cannot yet without additional engine changes do the type check in element symbol as we need to abuse the type system occasional - such as with the exception type since it's not a proper type. I'll leave this open for now. > 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 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2633) Criteria is assumed needed when no other predicates determined during RuleRaiseAccess

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-2633?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-2633: --------------------------------- Fix Version/s: 7.7.9 > Criteria is assumed needed when no other predicates determined during RuleRaiseAccess > ------------------------------------------------------------------------------------- > > Key: TEIID-2633 > URL: https://issues.jboss.org/browse/TEIID-2633 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7.7 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5, 7.7.9 > > > CanRaiseOverJoin method needs optimization in RuleRaiseAccess.java. A pushed join is assumed to need criteria based upon lack of predicates. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2808) Oversights in parser test unit tests

by Paul Richardson (JIRA)

[ https://issues.jboss.org/browse/TEIID-2808?page=com.atlassian.jira.plugin... ] Paul Richardson updated TEIID-2808: ----------------------------------- Attachment: 0001-TEIID-2808-Small-fixes-to-unit-tests-and-accompanyin.patch [~shawkins] Attaching patch taking into account your comments. This is a git commit against 8.6.Final but I would imagine it will apply against whichever branch you're currently working off. Certainly, patch should take care of it. > 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 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, 11 months

1
0
0 / 0

[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 commented on TEIID-2808: --------------------------------------- I would suggest just submitting a patch for all this as it will be even more clear what you mean. > Suggestion is change the expected Constant to have NullType as its 'type' rather than Object. There is a case to be made either way. I'm fine with how it is currently or by looking at the type in addition to value object. > The Block node class has no equals method hence this test passes even though the 'groupExpression' field is different between expected and actual. Block does have an equality method. Do you mean a different class? > Has an extraneous query created and never used Yes I'm sure you can find quite a bit of stuff in the tests. The code has been tidied up over the years, but not completely. > Never executes due to a lack of \@Test annotation. It should just have an \@Ignore We don't need to have it as an expected failure as it's not a desirable failure. > The reason is that GroupSymbol equals method does not test the 'shortname' field if the schema is null. This maybe by design? Without a schema we know the groupsymbol is unresolved and is tested for equality based upon it's "full name". However the equality check here is in the SubqueryFromClause, which is not case sensitive. Previously the groupsymbol checks were case insensitive as well. > 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 > > 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 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2673) CNF exception when getting data through infinispan-cache translator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2673?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2673: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1011502|https://bugzilla.redhat.com/show_bug.cgi?id=1011502] from ON_QA to VERIFIED > CNF exception when getting data through infinispan-cache translator > ------------------------------------------------------------------- > > Key: TEIID-2673 > URL: https://issues.jboss.org/browse/TEIID-2673 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4.1 > Reporter: Van Halbert > Assignee: Van Halbert > Labels: infinispan > Fix For: 8.4.1, 8.7 > > > When getting data through infinispan-cache translator using remote hot rod access, DV will throw "...ClassNotFoundException: org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory". > Workaround: > Add "<module name="org.infinispan.client.hotrod"/>" as a dependency into module "org.jboss.teiid". -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2808) Oversights in parser test unit tests

by Paul Richardson (JIRA)

Paul Richardson created TEIID-2808: -------------------------------------- Summary: 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.6, 8.4 Reporter: Paul Richardson Assignee: Steven Hawkins Priority: Minor 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 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2807) Remove connector-template, replaced by teiid-tools connector-archetype

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2807?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-2807: ------------------------------- Git Pull Request: https://github.com/teiid/teiid/pull/178 > Remove connector-template, replaced by teiid-tools connector-archetype > ----------------------------------------------------------------------- > > Key: TEIID-2807 > URL: https://issues.jboss.org/browse/TEIID-2807 > Project: Teiid > Issue Type: Task > Components: Tools > Affects Versions: 8.7 > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Minor > > Remove the connector-template project. The connector-archetype now provides the ability to generate a connector project. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2807) Remove connector-template, replaced by teiid-tools connector-archetype

by Van Halbert (JIRA)

Van Halbert created TEIID-2807: ---------------------------------- Summary: Remove connector-template, replaced by teiid-tools connector-archetype Key: TEIID-2807 URL: https://issues.jboss.org/browse/TEIID-2807 Project: Teiid Issue Type: Task Components: Tools Affects Versions: 8.7 Reporter: Van Halbert Assignee: Steven Hawkins Priority: Minor Remove the connector-template project. The connector-archetype now provides the ability to generate a connector project. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2788) Create maven archtype for translator development

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2788?page=com.atlassian.jira.plugin... ] Van Halbert resolved TEIID-2788. -------------------------------- Fix Version/s: 8.6 Resolution: Done The Teiid-tools has been setup that contains the archetype for translators: https://github.com/teiid/teiid-tools/tree/master/arche-types/translator-a... > Create maven archtype for translator development > ------------------------------------------------ > > Key: TEIID-2788 > URL: https://issues.jboss.org/browse/TEIID-2788 > Project: Teiid > Issue Type: Feature Request > Components: Tools > Affects Versions: 8.7 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Optional > Fix For: 8.6 > > > Create a maven archtype project for creating translator projects. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2789) Create maven archtype for connector development

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2789?page=com.atlassian.jira.plugin... ] Van Halbert resolved TEIID-2789. -------------------------------- Fix Version/s: 8.6 Resolution: Done The Teiid-tools project has been created, and it contains the archetype for connectors at: https://github.com/teiid/teiid-tools/tree/master/arche-types/connector-ar... > Create maven archtype for connector development > ----------------------------------------------- > > Key: TEIID-2789 > URL: https://issues.jboss.org/browse/TEIID-2789 > Project: Teiid > Issue Type: Feature Request > Components: Tools > Affects Versions: 8.7 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Optional > Fix For: 8.6 > > > Create a maven archtype project for creating the archetype that can be used for connector development -- 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2014