[ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-170: ---------------------------------------- There are two approaches: 1. Handle this as part of codegen based upon ddl/cr. This minimizes changes to the core. 2. Push the handling into the core. This requires adding the concept of an implicit source, something that can be injected into the vdb like our system schema, but with a schema that is generated based upon the materialization targets. Either way we have an issue of discoverability - if/where is the infinipsan operator installed. A lot depends on the assumption of an infinispan cluster per vdb, or a shared cluster for all vdbs. If shared then we need to account for that in the cache naming strategy - in general it be vdb_table_fqn (version would need to be accounted for in core version). We would also only delete the needed caches on start-up/shut-down, rather than destroying the entire cluster. Note the need for the fqn as we can have materialized views in multiple schema in vdb in general, which would all point to the same source schema/cluster. If we do create a cluster per vdb, then the operator will likely need we need the operator to manage the creation / destruction of the cluster (using a cr like the one shown with the transactional cache example) upon the vdb being deployed / undeployed. There is also an issue of security. We can hide the materialization target schema, but we also need to consider if access is allowed at all. At least for syndesis org.teiid.hiddenMetadataResolvable is always set to false so there's not an issue there. In core/teiid spring boot we may need to drive that on a per schema basis. Also captured TEIID-5916 so that we can reach feature parity with internal materialization indexing. It appears we need to change how we are using the Indexed annotation. -- This message was sent by Atlassian Jira (v7.13.8#713008)