Yes, I am thinking Operator should have the scheduler to invoke the materialization actions, based on responses it should keep track of the status.

I do not think I follow you on this one, i understand writing batches to JDG.

Caching and materialization changes for JDG / OpenShift ------------------------------------------------------- Key: TEIIDSB-147 URL: https://issues.jboss.org/browse/TEIIDSB-147 Project: Teiid Spring Boot Issue Type: Enhancement Components: core, OpenShift Reporter: Steven Hawkins Assignee: Ramesh Reddy Priority: Major Fix For: 1.3.0 Started this as a higher level issue in Teiid Spring Boot rather than core Teiid since the work won't align well to Teiid 13.1, but some things may need addressed there as well. Things break down roughly into: * Single-pod support ** Define the expectations for how we'll be configured to hit a JDG instance - will it be a user exercise to create if it doesn't exist, will we need to create, will the be a crd strategy for creation, and will it be multi-tenet? There is also the issue / assumption of cache sharing based upon vdb name - is that sufficient for now? ** validate external materialization to JDG likely using a transactional upsert strategy to avoid issues like TEIID-5436 * Multi-pod support ** everything from single-pod support ** Result set caching needs to directly write batches / results to JDG rather than relying upon on demand replication. ** requires replacing the logic that detect failed materialization loads ** internal materialization replacement needs to based upon something more like external materialization, but that can be seen as a next step that is turnkey internal materialization to JDG (little to no user setup required)