[
https://issues.jboss.org/browse/TEIID-4626?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-4626:
-------------------------------------
[~shawkins] For this JIRA, how about,
- Add another column to {{Status}} table called "RefreshType", with values
"EAGER, LAZY".
- Add an extension property on View to select the type of refresh. Default to
"LAZY"
- When "LoadMatView" procedure runs it sets the LoadNumber to 'n' on the
materialized 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.
What do you think, will this work?
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)