[JBoss JIRA] (TEIID-4493) Add support for integration with qgis
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4493?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4493:
---------------------------------------
Full binary cursor support is unfortunately needed, but I am able to successfully process at least the validation logic from there. Based upon the work done so far and from what I can see in their source this needs about 3 more days of work to round out testing and the implementation to reach an initial level of completion.
> Add support for integration with qgis
> --------------------------------------
>
> Key: TEIID-4493
> URL: https://issues.jboss.org/browse/TEIID-4493
> Project: Teiid
> Issue Type: Enhancement
> Components: Documentation, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> Similar to our support for GeoServer, we should support qgis integration if possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4558) Query Plan Analyzer
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4558?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4558:
------------------------------------
TEIID-2052 talks about query plan problem resolving. These 2 jira's maybe covering the same territory regarding how to assist the user with better information about the query plan, including suggestions.
> Query Plan Analyzer
> -------------------
>
> Key: TEIID-4558
> URL: https://issues.jboss.org/browse/TEIID-4558
> Project: Teiid
> Issue Type: Feature Request
> Components: Tools
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> Provide a tool that would take a query plan and provide feed back.
> Example:
> - indicate where there maybe a problem in the structure of the query that may impact performance
> - indicate in the plan where there maybe issues (like table scan, no rows, etc.)
> - provide recommendations for improving performance
> etc..
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4516) Add support for updating child objects
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4516?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4516:
------------------------------------
Changed this to only refer enabling updates. Deletes will be enabled under the TEIID-4517 jira.
> Add support for updating child objects
> --------------------------------------
>
> Key: TEIID-4516
> URL: https://issues.jboss.org/browse/TEIID-4516
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 9.2, 8.12.7.6_3
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Critical
> Fix For: 9.2
>
>
> When using complex pojo with JDG 6.6, updating child tables doesn't do anything. It doesn't update the rows, but neither throws exception.
> The problem appears for both usages of JDG cache (annotated POJOs, protobuf+marshaller). I have following pojo structure:
> {code:plain}
> package org.jboss.qe.jdg.remote.protobuf.complex;
> /* @Indexed */
> message Person {
>
> /* @IndexedField(index=true, store=false) */
> required int32 id = 1;
>
> /* @IndexedField */
> required string name = 2;
>
> /* @IndexedField */
> optional string email = 3;
>
> /* @IndexedField(index=true, store=false) */
> repeated PhoneNumber phones = 4;
> /* @Indexed */
> message Address {
>
> /* @IndexedField */
> required string Address = 1;
>
> /* @IndexedField(index=true, store=false) */
> required string City = 2;
>
> /* @IndexedField(index=true, store=false) */
> required string State = 3;
> }
> /* @IndexedField(index=true, store=false) */
> optional Address address = 5;
> }
>
> /* @Indexed */
> message PhoneNumber {
>
> /* @IndexedField */
> required string number = 1;
> }
> {code}
> That is, one top-level POJO class Person, and two child POJO classes: Address(1-to-1) and PhoneNumber(1-to-N). Neither Address nor PhoneNumber tables could be updated. The DDL is following:
> {code:sql}
> CREATE FOREIGN TABLE Address (
> Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address')
> ) OPTIONS (UPDATABLE TRUE);
>
> CREATE FOREIGN TABLE Person (
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> CONSTRAINT PK_ID PRIMARY KEY(id)
> ) OPTIONS (UPDATABLE TRUE);
>
> CREATE FOREIGN TABLE PhoneNumber (
> number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones')
> ) OPTIONS (UPDATABLE TRUE);
> {code}
> INSERT queries to prepare data:
> {code:sql}
> INSERT INTO Person(id,name,email) VALUES (1,'name1','email1')
> INSERT INTO Address(id,Address,City,State) VALUES (1,'address1','city1','state1')
> INSERT INTO PhoneNumber(id, number) VALUES (1, '001234567')
> INSERT INTO PhoneNumber(id, number) VALUES (1, '001234568')
> {code}
> UPDATE queries and queries for checking results:
> * 1-to-1
> {code:sql}UPDATE Address SET city='newCity' WHERE id=1{code}
> {code:sql}SELECT * FROM Person,Address{code}
> * 1-to-n
> {code:sql}UPDATE PhoneNumber SET number='newNumber' WHERE id=1{code}
> {code:sql}SELECT * FROM Person,PhoneNumber{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4516) Add support for updating child objects
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4516?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4516:
-------------------------------
Summary: Add support for updating child objects (was: Add support for updating/deleting child objects)
> Add support for updating child objects
> --------------------------------------
>
> Key: TEIID-4516
> URL: https://issues.jboss.org/browse/TEIID-4516
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 9.2, 8.12.7.6_3
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Critical
> Fix For: 9.2
>
>
> When using complex pojo with JDG 6.6, updating child tables doesn't do anything. It doesn't update the rows, but neither throws exception.
> The problem appears for both usages of JDG cache (annotated POJOs, protobuf+marshaller). I have following pojo structure:
> {code:plain}
> package org.jboss.qe.jdg.remote.protobuf.complex;
> /* @Indexed */
> message Person {
>
> /* @IndexedField(index=true, store=false) */
> required int32 id = 1;
>
> /* @IndexedField */
> required string name = 2;
>
> /* @IndexedField */
> optional string email = 3;
>
> /* @IndexedField(index=true, store=false) */
> repeated PhoneNumber phones = 4;
> /* @Indexed */
> message Address {
>
> /* @IndexedField */
> required string Address = 1;
>
> /* @IndexedField(index=true, store=false) */
> required string City = 2;
>
> /* @IndexedField(index=true, store=false) */
> required string State = 3;
> }
> /* @IndexedField(index=true, store=false) */
> optional Address address = 5;
> }
>
> /* @Indexed */
> message PhoneNumber {
>
> /* @IndexedField */
> required string number = 1;
> }
> {code}
> That is, one top-level POJO class Person, and two child POJO classes: Address(1-to-1) and PhoneNumber(1-to-N). Neither Address nor PhoneNumber tables could be updated. The DDL is following:
> {code:sql}
> CREATE FOREIGN TABLE Address (
> Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address')
> ) OPTIONS (UPDATABLE TRUE);
>
> CREATE FOREIGN TABLE Person (
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> CONSTRAINT PK_ID PRIMARY KEY(id)
> ) OPTIONS (UPDATABLE TRUE);
>
> CREATE FOREIGN TABLE PhoneNumber (
> number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
> id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones')
> ) OPTIONS (UPDATABLE TRUE);
> {code}
> INSERT queries to prepare data:
> {code:sql}
> INSERT INTO Person(id,name,email) VALUES (1,'name1','email1')
> INSERT INTO Address(id,Address,City,State) VALUES (1,'address1','city1','state1')
> INSERT INTO PhoneNumber(id, number) VALUES (1, '001234567')
> INSERT INTO PhoneNumber(id, number) VALUES (1, '001234568')
> {code}
> UPDATE queries and queries for checking results:
> * 1-to-1
> {code:sql}UPDATE Address SET city='newCity' WHERE id=1{code}
> {code:sql}SELECT * FROM Person,Address{code}
> * 1-to-n
> {code:sql}UPDATE PhoneNumber SET number='newNumber' WHERE id=1{code}
> {code:sql}SELECT * FROM Person,PhoneNumber{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4519) JDG prevent execution of delete or update on child objects
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4519?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4519:
------------------------------------
With TEIID-4517 for 9.2, this jira will not be needed. These changes only apply to 8.12.x
> JDG prevent execution of delete or update on child objects
> ----------------------------------------------------------
>
> Key: TEIID-4519
> URL: https://issues.jboss.org/browse/TEIID-4519
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.7.6_3
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Critical
> Fix For: 8.12.7.6_3
>
>
> When using JDG and complex pojos, delete query issued against child tables end with error.
> * 1-1 relation:
> When deleting a child object, whole parent object is deleted
> * 1-n relation:
> An exception is thrown:
> {code:plain}
> 13:31:28,926 WARN [org.teiid.CONNECTOR] (Worker7_QueryProcessorQueue91) Connector worker process failed for atomic-request=rKsoeHUfbaAW.21.0.21: org.teiid.translator.TranslatorException: TEIID31111 No such accessible property/method number on class java.util.ArrayList.
> at org.teiid.translator.object.ObjectUpdateExecution.handleDelete(ObjectUpdateExecution.java:388) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.executeUpdate(ObjectUpdateExecution.java:137) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.execute(ObjectUpdateExecution.java:100) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:402) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_102]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at com.sun.proxy.$Proxy81.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_102]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102]
> Caused by: javax.script.ScriptException: TEIID31111 No such accessible property/method number on class java.util.ArrayList.
> at org.teiid.translator.object.ObjectScriptEngine$1.eval(ObjectScriptEngine.java:144) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.handleDelete(ObjectUpdateExecution.java:372) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> ... 20 more
> {code}
> These two cases should be handled. Given the lack of DELETE support, all the DELETE queries on child entities should throw exception instead.
> The DELETE on parent should be enabled though.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4519) JDG prevent execution of delete or update on child objects
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4519?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4519:
-------------------------------
Fix Version/s: (was: 9.2)
> JDG prevent execution of delete or update on child objects
> ----------------------------------------------------------
>
> Key: TEIID-4519
> URL: https://issues.jboss.org/browse/TEIID-4519
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.7.6_3
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Critical
> Fix For: 8.12.7.6_3
>
>
> When using JDG and complex pojos, delete query issued against child tables end with error.
> * 1-1 relation:
> When deleting a child object, whole parent object is deleted
> * 1-n relation:
> An exception is thrown:
> {code:plain}
> 13:31:28,926 WARN [org.teiid.CONNECTOR] (Worker7_QueryProcessorQueue91) Connector worker process failed for atomic-request=rKsoeHUfbaAW.21.0.21: org.teiid.translator.TranslatorException: TEIID31111 No such accessible property/method number on class java.util.ArrayList.
> at org.teiid.translator.object.ObjectUpdateExecution.handleDelete(ObjectUpdateExecution.java:388) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.executeUpdate(ObjectUpdateExecution.java:137) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.execute(ObjectUpdateExecution.java:100) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:402) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_102]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at com.sun.proxy.$Proxy81.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_102]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.6.6_3-redhat-1.jar:8.12.6.6_3-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102]
> Caused by: javax.script.ScriptException: TEIID31111 No such accessible property/method number on class java.util.ArrayList.
> at org.teiid.translator.object.ObjectScriptEngine$1.eval(ObjectScriptEngine.java:144) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> at org.teiid.translator.object.ObjectUpdateExecution.handleDelete(ObjectUpdateExecution.java:372) [translator-object-8.12.6.6_3.jar:8.12.6.6_3]
> ... 20 more
> {code}
> These two cases should be handled. Given the lack of DELETE support, all the DELETE queries on child entities should throw exception instead.
> The DELETE on parent should be enabled though.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4526) Integrate with Debezium for CDC for maintaining materialized views
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4526?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4526:
---------------------------------------
In developing a plan for CDC integration near term work could include:
- further enhance/refine the built in materialization management (both internal and external) to support alternative invalidation and refresh strategies. Full snapshot refresh is supported by both internal/external, and a predicate based invalidation is supported for external. The latter potentially allows for more control, but does not re-enforce a particular strategy, must be called manually, and relies upon a built-in delete, then insert - which is problematic when a source is not transactional and should be changed to a merge/delete approach. Other approaches such as lazy invalidation down to a row level require the materialization table to some natural or additional column that allows for row to be identified as stale.
- However providing out of the box built-in eager or lazy invalidation to a row level implies that routines for CDC events that goes well beyond our current logic around inherently updatable views. I don't think we should assume that it would be developed for Teiid 9.2, which should imply that we do want high-level plugability of event handling. This could even be handled at the language level with new trigger semantics for source tables: create trigger on tbl on cdc (insert|update...) - which could potentially even specify the topic mapping other details. There is complexity for multi-source models here though.
- Provide debezium based out of the box support for result set cache invalidation built upon the current table level update event logic.
- consider the benefits of consolidating status table management as suggested by [~kylin]
> Integrate with Debezium for CDC for maintaining materialized views
> ------------------------------------------------------------------
>
> Key: TEIID-4526
> URL: https://issues.jboss.org/browse/TEIID-4526
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
>
> Integrate with Debezium so that Teiid will be able to consume and react to the row-level change events and do something interesting with them, such as update the materialized view(s).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months