[
https://issues.jboss.org/browse/TEIID-4626?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-4626:
-------------------------------------
Yes, I was thinking at row level updates. Your comments are for View level then. Couple
comments
- there will be no 1-to-1 correlation as to how many rows changed but how many updates
could have affected it.
- this be hard to guess how stale the view really is?
- but this would be fast and non-invasive, but would require to run a full snapshot
update.
Coming to tracking the number of updates, are u thinking we need an additional column on
{Status}} table to track this per View? Or should we track each source table's update
statistics?
Should we try to automatically insert the "after triggers" for above based on
the View transformation?
As per triggering an update after n updates, are thinking as absolute number or should we
do some kind of percentage based on the {{Cardinality}} metric in the {{Status}} table?
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)