June 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4236) OData - incorrect SQL in example

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4236?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4236. ----------------------------------- Fix Version/s: 9.0 Resolution: Done Corrected the odata2/4 examples. > OData - incorrect SQL in example > -------------------------------- > > Key: TEIID-4236 > URL: https://issues.jboss.org/browse/TEIID-4236 > Project: Teiid > Issue Type: Bug > Components: Documentation > Affects Versions: 9.0 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 9.0 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4235) dynamic sql recursion check not valid after caught exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4235?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4235: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1341654 Bugzilla Update: Perform > dynamic sql recursion check not valid after caught exception > ------------------------------------------------------------ > > Key: TEIID-4235 > URL: https://issues.jboss.org/browse/TEIID-4235 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.13.5 > > > With a procedure like: > begin > execute immediate > exception e > ... > execute immediate ... > An exception on the second execute immediate will be seen like: > org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE ..." due to: TEIID30347 There is a recursive invocation of group 'proc'. Please correct the SQL. > Even when the dynamic sql does not re-invoke the proc. The issue is that when catching the initial exception thrown doesn't clear the entry from the recursion stack. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4235) dynamic sql recursion check not valid after caught exception

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4235?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4235. ----------------------------------- Fix Version/s: 8.13.5 Resolution: Done Updated the logic to properly clear the recursion check. > dynamic sql recursion check not valid after caught exception > ------------------------------------------------------------ > > Key: TEIID-4235 > URL: https://issues.jboss.org/browse/TEIID-4235 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.13.5 > > > With a procedure like: > begin > execute immediate > exception e > ... > execute immediate ... > An exception on the second execute immediate will be seen like: > org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE ..." due to: TEIID30347 There is a recursive invocation of group 'proc'. Please correct the SQL. > Even when the dynamic sql does not re-invoke the proc. The issue is that when catching the initial exception thrown doesn't clear the entry from the recursion stack. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3999) more aspects of materialization metadata should be validated

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3999?page=com.atlassian.jira.plugin... ] Kylin Soong commented on TEIID-3999: ------------------------------------ > Are there anymore aspects (such as if the tables are marked as updatable) that we want to validate for 9.0? How to validate? Current we have validation on Tables(mat table, stage table, status table), another aspect is load scripts validation, is there any good ways to validate the load scripts? > more aspects of materialization metadata should be validated > ------------------------------------------------------------ > > Key: TEIID-3999 > URL: https://issues.jboss.org/browse/TEIID-3999 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Kylin Soong > Priority: Minor > Fix For: 9.0 > > > * During metadata load we should check if the status table and the materialization scripts are valid, so there is at least a log of the issue rather than waiting for the exception to occur once the vdb is active. > * According to TEIID-4203, add an initial validation that validate the status table definition matches the expectation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ] Kylin Soong resolved TEIID-4121. -------------------------------- Resolution: Done Set to resolve due to some change of document. > Enhancing the External Materialization > -------------------------------------- > > Key: TEIID-4121 > URL: https://issues.jboss.org/browse/TEIID-4121 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Affects Versions: 9.x > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 9.0 > > > The intention of move "status" table to physical database is to increase durable and fully control refresh and loading, but it increase the complexity. > The "status" table by design should unique for whole VDB, if you look the https://teiid.gitbooks.io/documents/content/caching/External_Materializat..., the table structure: > {code:sql} > CREATE TABLE status > ( > VDBName varchar(50) not null, > VDBVersion integer not null, > SchemaName varchar(50) not null, > Name varchar(256) not null, > TargetSchemaName varchar(50), > TargetName varchar(256) not null, > Valid boolean not null, > LoadState varchar(25) not null, > Cardinality long, > Updated timestamp not null, > LoadNumber long not null, > PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name) > ); > {code} > but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope. > From finishedDeployment logic in MaterializationManager, MATERIALIZED_TABLE be used to determine whether the Mat is internal or external, But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4236) OData - incorrect SQL in example

by Juraj Duráni (JIRA)

[ https://issues.jboss.org/browse/TEIID-4236?page=com.atlassian.jira.plugin... ] Juraj Duráni updated TEIID-4236: -------------------------------- Affects Version/s: 9.0 > OData - incorrect SQL in example > -------------------------------- > > Key: TEIID-4236 > URL: https://issues.jboss.org/browse/TEIID-4236 > Project: Teiid > Issue Type: Bug > Components: Documentation > Affects Versions: 9.0 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4236) OData - incorrect SQL in example

by Juraj Duráni (JIRA)

Juraj Duráni created TEIID-4236: ----------------------------------- Summary: OData - incorrect SQL in example Key: TEIID-4236 URL: https://issues.jboss.org/browse/TEIID-4236 Project: Teiid Issue Type: Bug Components: Documentation Reporter: Juraj Duráni Assignee: Steven Hawkins -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4121: --------------------------------------- The recursion issue is captured as TEIID-4235 > Enhancing the External Materialization > -------------------------------------- > > Key: TEIID-4121 > URL: https://issues.jboss.org/browse/TEIID-4121 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Affects Versions: 9.x > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 9.0 > > > The intention of move "status" table to physical database is to increase durable and fully control refresh and loading, but it increase the complexity. > The "status" table by design should unique for whole VDB, if you look the https://teiid.gitbooks.io/documents/content/caching/External_Materializat..., the table structure: > {code:sql} > CREATE TABLE status > ( > VDBName varchar(50) not null, > VDBVersion integer not null, > SchemaName varchar(50) not null, > Name varchar(256) not null, > TargetSchemaName varchar(50), > TargetName varchar(256) not null, > Valid boolean not null, > LoadState varchar(25) not null, > Cardinality long, > Updated timestamp not null, > LoadNumber long not null, > PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name) > ); > {code} > but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope. > From finishedDeployment logic in MaterializationManager, MATERIALIZED_TABLE be used to determine whether the Mat is internal or external, But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 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 June 2016