[
https://issues.jboss.org/browse/TEIID-4626?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-4626:
---------------------------------------
Does the status table need the refresh type if it's already defined on the view?
When CDC event comes in, and processed through
"UpdateMatview", this procedure will update the affected column's LoadNumber
to -1, and this will also keep Status table's "Updated" column unmodified.
When TTL event occurs, if LAZY, "LoadMatView" procedure updates all the rows
with LoadNumber -1. If EAGER, depending upon Status table's Updated column this will
either run or do a SNAPSHOT re-load.
This doesn't quite match the expected semantics of eager. You would expect eager to
do something on every event, not based upon TTL.
More than likely you would see this as an alternative or in addition to the TTL refresh
approach. Such that after n update events we'll refresh - where n would likely be
based upon the number of rows/columns.
Add a full snapshot refresh strategy based upon table modifications
-------------------------------------------------------------------
Key: TEIID-4626
URL:
https://issues.jboss.org/browse/TEIID-4626
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Fix For: 9.3
using the existing full materialization refresh logic we can trigger a refresh based upon
a notion of how dirty a table is based upon a proportion of rows updated to the rows in
the table. This would also require some change to the status table to capture the number
of transitive row updates. This could then be hooked up to debezium as the event source.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)