[teiid-issues] [JBoss JIRA] (TEIID-4626) Add a full snapshot refresh strategy based upon table modifications

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368434#comment-13368434 ] 

Steven Hawkins commented on TEIID-4626:
---------------------------------------

> Couple comments

Those are essentially correct - it's just providing an avenue for full refresh beyond TTL.

> 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?

We need the transitive graph of all source tables contributing to the view, then any modification to those would count as a modification that yes would be tracked on the status table.

We already have logic with the result set caching functions similar to this.  The cache tracks all objects that contribute to a given result and looks for modifications after the creation of the cache entry to invalidate the entry.

> Should we try to automatically insert the "after triggers" for above based on the View transformation?

That's certainly possible to do.  Any alter view / alter procedure may mean that we'll have to add / drop triggers.

> 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?

The intent was to use some proportion or percentage based upon the 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)