[JBoss JIRA] (TEIID-4166) JDG remote cache translator (DSL) - In predicate does not support more than 1024 values
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4166?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4166:
-------------------------------
Summary: JDG remote cache translator (DSL) - In predicate does not support more than 1024 values (was: JDG cache translator - In predicate does not support more than 1024 values)
> JDG remote cache translator (DSL) - In predicate does not support more than 1024 values
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-4166
> URL: https://issues.jboss.org/browse/TEIID-4166
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.12.x
> Reporter: Juraj Duráni
> Assignee: Van Halbert
>
> JDG cache translator (local JDG) does not support more than 1024 values in IN predicate.
> The exception is thrown because 'maxClauseCount' is set to 1024.
> *Exception:*
> {code:plain}
> 12:27:43,579 ERROR [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue73) TEIID30019 Unexpected exception for request Q4A3h+Gv1LIh.13: org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set to 1024
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:136)
> at org.hibernate.search.query.dsl.impl.BooleanQueryBuilder.createQuery(BooleanQueryBuilder.java:115)
> at org.hibernate.hql.lucene.internal.builder.predicate.LuceneDisjunctionPredicate.getQuery(LuceneDisjunctionPredicate.java:51)
> at org.hibernate.hql.lucene.internal.builder.predicate.LuceneInPredicate.getQuery(LuceneInPredicate.java:60)
> at org.hibernate.hql.lucene.internal.builder.predicate.LuceneInPredicate.getQuery(LuceneInPredicate.java:35)
> at org.hibernate.hql.lucene.internal.builder.predicate.LuceneRootPredicate.getQuery(LuceneRootPredicate.java:42)
> at org.hibernate.hql.lucene.internal.builder.predicate.LuceneRootPredicate.getQuery(LuceneRootPredicate.java:32)
> at org.hibernate.hql.ast.spi.SingleEntityQueryBuilder.build(SingleEntityQueryBuilder.java:174)
> at org.hibernate.hql.lucene.internal.LuceneQueryRendererDelegate.getResult(LuceneQueryRendererDelegate.java:98)
> at org.hibernate.hql.lucene.LuceneProcessingChain.getResult(LuceneProcessingChain.java:157)
> at org.hibernate.hql.lucene.LuceneProcessingChain.getResult(LuceneProcessingChain.java:49)
> at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:89)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.transformJpaToLucene(QueryEngine.java:708)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildLuceneQuery(QueryEngine.java:676)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedLuceneQuery.createCacheQuery(EmbeddedLuceneQuery.java:59)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedLuceneQuery.listInternal(EmbeddedLuceneQuery.java:74)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedLuceneQuery.list(EmbeddedLuceneQuery.java:68)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:45)
> at org.teiid.resource.adapter.infinispan.DSLSearch.performSearch(DSLSearch.java:169)
> at org.teiid.resource.adapter.infinispan.DSLSearch.performSearch(DSLSearch.java:130)
> at org.teiid.translator.object.ObjectExecution.execute(ObjectExecution.java:259)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:359) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-internal]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at com.sun.proxy.$Proxy81.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.5.redhat-3.jar:8.12.5.redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[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 commented on TEIID-4121:
------------------------------------
A quick question, does the [1] ways still work, from MaterializationManager.java FinishDeployment(), seems this method will invoke SYSADMIN.loadMatView, and SYSADMIN.loadMatView depend on a *staging table*, a *status table* be created in physical source, but [1] not refer any of them, so my question:
# Does [1] docs works? refer to "your index creation may be more performant if deferred until after the table has been created", how to understand the 'index creation' and 'table has been created'?
# Does Dsigner Tools designed external Mat View VDB works in DV 6.x?
[1] https://teiid.gitbooks.io/documents/content/caching/External_Materializat...
> 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)
8 years, 7 months
[JBoss JIRA] (TEIID-4231) OData - NPE when accessing inactive vdb
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4231?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4231:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1340429
Bugzilla Update: Perform
> OData - NPE when accessing inactive vdb
> ---------------------------------------
>
> Key: TEIID-4231
> URL: https://issues.jboss.org/browse/TEIID-4231
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Affects Versions: 8.12.5
> Reporter: Filip Elias
> Assignee: Steven Hawkins
>
> Teiid throws NPE when user tries to access inactive vdb via OData4.
> Exception:
> {code}
> 209 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-localhost/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.lang.NullPointerException
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.LocalClient.getMetadataStore(LocalClient.java:176) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:46) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:223) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-4231) OData - NPE when accessing inactive vdb
by Filip Elias (JIRA)
[ https://issues.jboss.org/browse/TEIID-4231?page=com.atlassian.jira.plugin... ]
Filip Elias updated TEIID-4231:
-------------------------------
Parent: TEIID-4032
Issue Type: Sub-task (was: Bug)
> OData - NPE when accessing inactive vdb
> ---------------------------------------
>
> Key: TEIID-4231
> URL: https://issues.jboss.org/browse/TEIID-4231
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Affects Versions: 8.12.5
> Reporter: Filip Elias
> Assignee: Steven Hawkins
>
> Teiid throws NPE when user tries to access inactive vdb via OData4.
> Exception:
> {code}
> 209 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-localhost/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.lang.NullPointerException
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.LocalClient.getMetadataStore(LocalClient.java:176) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:46) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:223) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-4231) OData - NPE when accessing inactive vdb
by Filip Elias (JIRA)
Filip Elias created TEIID-4231:
----------------------------------
Summary: OData - NPE when accessing inactive vdb
Key: TEIID-4231
URL: https://issues.jboss.org/browse/TEIID-4231
Project: Teiid
Issue Type: Bug
Components: OData
Affects Versions: 8.12.5
Reporter: Filip Elias
Assignee: Steven Hawkins
Teiid throws NPE when user tries to access inactive vdb via OData4.
Exception:
{code}
209 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-localhost/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.lang.NullPointerException
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.LocalClient.getMetadataStore(LocalClient.java:176) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:46) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:223) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100) [teiid-olingo-8.12.5.redhat-4.jar:8.12.5.redhat-4]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
13:23:41,210 INFO [MultiPlatformProcessRunner] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-4211) Wrong rewriting of CTEs when pushed down to PostgreSQL
by Salvatore R (JIRA)
[ https://issues.jboss.org/browse/TEIID-4211?page=com.atlassian.jira.plugin... ]
Salvatore R commented on TEIID-4211:
------------------------------------
Thanks for addressing and fixing this problem.
I downloaded the latest code from the master including this issue and I am experiencing another problem.
I defined the following view:
{code:sql}
create view v1 as
WITH mycte as (SELECT 1 as col1) SELECT col1 FROM mycte;
{code}
If I run this query:
{code:sql}
WITH mycte as (SELECT * FROM views.v1) SELECT * from mycte ;
{code}
it fails on generate the query plan with this exception:
{code}
TEIID31124 Recursive plan detected. Command type Query was already issued against mycte. Planning cycle: [Query mycte, Query views.v1]
{code}
Using /*+ no_inline */ hint to prevent the inlining doesn't fail and returns the correct result.
I wondered if this is an expected behavior in Teiid, since similar queries work correctly in databases like PostgreSQL, for example.
> Wrong rewriting of CTEs when pushed down to PostgreSQL
> ------------------------------------------------------
>
> Key: TEIID-4211
> URL: https://issues.jboss.org/browse/TEIID-4211
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.13.4
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.5
>
>
> Running the following query:
> {code:sql}
> WITH
> cte1 as (SELECT * from pg.test_a),
> cte2 as (select * from cte1),
> cte3 as (select * from cte1)
> SELECT * FROM cte2 join cte3 on cte2.a=cte3.a
> {code}
> where pg.test_a is a table defined in PostgreSQL, this exception is thrown:
> {code:sql}
> 19:42:22,287 WARN [org.teiid.CONNECTOR] (Worker20_QueryProcessorQueue228) ezaCNEtY3C+P Connector worker process failed for atomic-request=ezaCNEtY3C+P.121.3.48: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: WITH cte1 (a, b) AS (SELECT g_0."a", g_0."b" FROM "public"."test_a" AS g_0), cte1 (a, b) AS (SELECT g_0."a", g_0."b" FROM "public"."test_a" AS g_0), cte2 (a,b) AS (SELECT g_0.a, g_0.b FROM cte1 AS g_0), cte3 (a, b) AS (SELECT g_0.a, g_0.b FROM cte1 AS g_0) SELECT g_1.a, g_1.b, g_0.a, g_0.b FROM cte2 AS g_0, cte3 AS g_1 WHERE g_0.a = g_1.a]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:359)
> at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy56.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.postgresql.util.PSQLException: ERROR: WITH query name "cte1" specified more than once
> Position: 78
> at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
> at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
> at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:302)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123)
> ... 17 more
> {code}
> I am not sure if the problem below might be also related, but an exception is thrown by running the following query with nested CTEs:
> {code:sql}
> WITH
> cte1 as (SELECT 1 as a)
> ,cte3 as (with cte3_1 as (select cte1.a from cte1 join pg.test_a t1 on cte1.a=t1.a) select * from cte3_1)
> SELECT * FROM cte3;;
> {code}
> The exception is:
> {code:sql}
> 20:00:37,731 WARN [org.teiid.PROCESSOR] (Worker21_QueryProcessorQueue239) ezaCNEtY3C+P TEIID30020 Processing exception for request ezaCNEtY3C+P.125 'TEIID30226 Temporary table "cte1" does not exist.'. Originally QueryProcessingException TempTableStore.java:564. Enable more detailed logging to see the entire stacktrace.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3952) Update to updatable internal materialized view should update the materialized view as well as the database
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3952?page=com.atlassian.jira.plugin... ]
Kylin Soong reassigned TEIID-3952:
----------------------------------
Assignee: Steven Hawkins (was: Kylin Soong)
> Update to updatable internal materialized view should update the materialized view as well as the database
> ----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3952
> URL: https://issues.jboss.org/browse/TEIID-3952
> Project: Teiid
> Issue Type: Enhancement
> Components: VDB
> Affects Versions: 8.7
> Environment: Red Hat JBoss Data Virtualization 6.2 based on Teiid 8.7.x
> Reporter: Andy Yuen
> Assignee: Steven Hawkins
> Labels: jboss
> Fix For: 9.1
>
>
> Updating an updatable internal materized view updates the database but not the materialized view at present. The requested enhancement is that they, both, should be updated.
> Setup
> Client - SquirrelSQL to access JDV
> JDV 6.2 - with an updatable nternal materialized view of one table from the data source
> Data Source - just one data source: MySQL
> I can see from the console that the target table/view has been materialized
> Then I did the following:
> 1) select a row from the materialized table
> 2) update a field in a row in the materialized view
> 3) select that row (value unchanged ie, same as int 1) - tried multiple times
> 4) issue EXEC SYSADMIN.refreshMatViewRow(...) using primary key for the row that has been changed
> 5) select that row (value unchanged) - now I can see the changed data
> This behaviour is counter-intuitive because I was expecting that since it is an updatable materialized view, my change will write through the materialized view ie, change both the materialized view as well as the database. But in this case, it changed the database and not the materialized view?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months