May 2017 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4913) MetadataFactory is not replacing . in column names

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4913?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4913: ---------------------------------- Summary: MetadataFactory is not replacing . in column names (was: MetadataFactory is not replace . in column names) > MetadataFactory is not replacing . in column names > -------------------------------------------------- > > Key: TEIID-4913 > URL: https://issues.jboss.org/browse/TEIID-4913 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > On import we are not automatically replacing . with _ > Also we are missing a validation that . is not allowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4913) MetadataFactory is not replace . in column names

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4913: ------------------------------------- Summary: MetadataFactory is not replace . in column names Key: TEIID-4913 URL: https://issues.jboss.org/browse/TEIID-4913 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins On import we are not automatically replacing . with _ Also we are missing a validation that . is not allowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4732) Teiid Server does not honor columns name in external materialization

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4732?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4732: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1418074, https://bugzilla.redhat.com/show_bug.cgi?id=1451823, https://bugzilla.redhat.com/show_bug.cgi?id=1418077 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1451823) Bugzilla Update: Perform > Teiid Server does not honor columns name in external materialization > -------------------------------------------------------------------- > > Key: TEIID-4732 > URL: https://issues.jboss.org/browse/TEIID-4732 > Project: Teiid > Issue Type: Bug > Components: Common > Affects Versions: 9.1.2 > Environment: * WildFly 10 > * Teiid Server 9.1.2 > * CentOs 7 > * MySQL 5.6.35 > Reporter: Pedro Inácio > Assignee: Steven Hawkins > Fix For: 9.0.6, 9.1.3, 8.7.12.6_2, 8.12.x-6.4, 8.12.11.6_3 > > Attachments: NumberingPlan.csv, externalMaterializationOrderProblem-vdb.xml, mySqlCreateTable.sql, numberingPlan-vdb.xml > > > When defining a View with external materialization, if the view does not specify the columns in the same order as they are defined in the Materialized Table, Teiid Server inserts data in the wrong columns (in the order that is defined in the view). It appears that Teiid Server does not use the columns names but instead uses the column indexes. > Example: > If the view is defined like this: > {code:sql} > CREATE VIEW my_view ( > cns varchar(400), > country_code varchar(400) > ) > {code} > And the tables in the database are defined like this: > {code:sql} > CREATE TABLE my_view_cache_staging ( > country_code VARCHAR(400), > cns VARCHAR(400) > > ); > CREATE TABLE my_view_cache ( > country_code VARCHAR(400), > cns VARCHAR(400) > ); > {code} > Then when loadMatView runs, it will insert in country_code column in database the values from cns (view) and in cns column in database the values from country_code (view). > But if the view is defined like this: > {code:sql} > CREATE VIEW my_view ( > country_code varchar(400), > cns varchar(400) > ) > {code} > Then Teiid will insert the data "correctly". > It appears that loadMatView is using indexes instead of column names to insert the data. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4875: ------------------------------- Fix Version/s: 8.12.x-6.4 Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1451870 > Planning issue with multiple aggregate decompositions through a join tree > ------------------------------------------------------------------------- > > Key: TEIID-4875 > URL: https://issues.jboss.org/browse/TEIID-4875 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3, 8.12.x-6.4, 9.2.3, 8.12.11.6_3 > > > The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups). > A query such as: > SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4 > With capabilities that disable join pushdown will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node. > java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null > at org.teiid.core.util.Assertion.failed(Assertion.java:73) > at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) > at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) > at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367) > at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133) > at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96) > at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102) > at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102) > at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91) > at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226) > at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138) > at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4446) Rationalize precision/scale

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4446?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4446: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1451867, https://bugzilla.redhat.com/show_bug.cgi?id=1445041 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1451867) Bugzilla Update: Perform > Rationalize precision/scale > --------------------------- > > Key: TEIID-4446 > URL: https://issues.jboss.org/browse/TEIID-4446 > Project: Teiid > Issue Type: Quality Risk > Components: OData, ODBC, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.12.x-6.4, 8.12.11.6_3 > > > Our handling of precision/scale is inconsistent. There are assumptions being made in the JDBC client, types.dat, the parser, and other paths that need to be explicit and consistent. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4446) Rationalize precision/scale

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4446?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4446: ------------------------------- Fix Version/s: 8.12.x-6.4 Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1451867 > Rationalize precision/scale > --------------------------- > > Key: TEIID-4446 > URL: https://issues.jboss.org/browse/TEIID-4446 > Project: Teiid > Issue Type: Quality Risk > Components: OData, ODBC, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.12.x-6.4, 8.12.11.6_3 > > > Our handling of precision/scale is inconsistent. There are assumptions being made in the JDBC client, types.dat, the parser, and other paths that need to be explicit and consistent. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4663) Support a more secure block mode for client/server encryption

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4663?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4663: ------------------------------- Fix Version/s: 8.12.x-6.4 > Support a more secure block mode for client/server encryption > ------------------------------------------------------------- > > Key: TEIID-4663 > URL: https://issues.jboss.org/browse/TEIID-4663 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver, Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0.6, 9.1.2, 9.2, 8.12.x-6.4, 8.12.11.6_3 > > > ECB is the current default for the socket transport encryption of secure messages. While this is relatively ok for small messages as we also have a message key acting as a CTR counter to some of the blocks, it does not provide strong security - especially for large data volume scenarios, such as when using larger login payloads or the secure requests option. We should default instead to CBC with an explicit initialization vector. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4663) Support a more secure block mode for client/server encryption

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4663?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4663: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1409823, https://bugzilla.redhat.com/show_bug.cgi?id=1451866 Bugzilla Update: Perform > Support a more secure block mode for client/server encryption > ------------------------------------------------------------- > > Key: TEIID-4663 > URL: https://issues.jboss.org/browse/TEIID-4663 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver, Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0.6, 9.1.2, 9.2, 8.12.11.6_3 > > > ECB is the current default for the socket transport encryption of secure messages. While this is relatively ok for small messages as we also have a message key acting as a CTR counter to some of the blocks, it does not provide strong security - especially for large data volume scenarios, such as when using larger login payloads or the secure requests option. We should default instead to CBC with an explicit initialization vector. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4722) TEIID30019: java.lang.AssertionError: Assertion failed assertion due to guard against a corner condition.

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4722?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4722: ------------------------------- Fix Version/s: 8.12.x-6.4 Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1419137, https://bugzilla.redhat.com/show_bug.cgi?id=1416482, https://bugzilla.redhat.com/show_bug.cgi?id=1451865 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1419137, https://bugzilla.redhat.com/show_bug.cgi?id=1416482) > TEIID30019: java.lang.AssertionError: Assertion failed assertion due to guard against a corner condition. > ----------------------------------------------------------------------------------------------------------- > > Key: TEIID-4722 > URL: https://issues.jboss.org/browse/TEIID-4722 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.10.6_2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.2, 9.1.3, 8.7.12.6_2, 8.12.x-6.4, 8.12.11.6_3 > > > Assertion failure: > {code:java} > ERROR [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue19151) TEIID30019 Unexpected exception for request WrzxYIqVWQ8G.11: java.lang.AssertionError: Assertion failed. > at org.teiid.core.util.Assertion.failed(Assertion.java:73) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.core.util.Assertion.assertTrue(Assertion.java:68) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.core.util.Assertion.assertTrue(Assertion.java:60) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.query.processor.relational.MergeJoinStrategy.setProcessingSortRight(MergeJoinStrategy.java:367) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.query.processor.relational.DependentAccessNode.prepareNextCommand(DependentAccessNode.java:162) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.query.processor.relational.AccessNode.openInternal(AccessNode.java:259) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:371) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4819) Tree page modifications removing the previous page, don't remove immediately

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4819?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4819: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1435233, https://bugzilla.redhat.com/show_bug.cgi?id=1451808, https://bugzilla.redhat.com/show_bug.cgi?id=1435239 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1451808) Bugzilla Update: Perform > Tree page modifications removing the previous page, don't remove immediately > ---------------------------------------------------------------------------- > > Key: TEIID-4819 > URL: https://issues.jboss.org/browse/TEIID-4819 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.9, 8.7.6.6_2 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.3, 8.12.x-6.4, 9.1.5, 9.2.2, 8.12.11.6_3 > > > TEIID-3119 introduced logic to reuse the existing cacheentry, but the removal of the old entry was based upon the wrong remove method - just a remove from cache and not memory. That would delay the cleanup of the memory reference until eviction or when the buffer/tree is removed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2017