[teiid-issues] [JBoss JIRA] (TEIIDSB-170) Automate materialization to JDG

[ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-170: ---------------------------------------- Continued from the pr about updating the regex for parsing comments and new lines: It's not really about a single comment, it's the complexity that it introduces to these regex expressions - anywhere you can have whitespace you can have a comment - and multi-line comments I believe would be pretty messy to capture. Options: * introduce a fuller parser to the operator. Problems still exist as you are doing a lot of contextual parsing here - assumptions about what schema we're creating things under for example. If we add support for create view schema.name - then that would break this. * Move the crd creation to Teiid Spring Boot where we are currently implicitly creating the caches. If we don't do this, we'll need to set the translator to not create if a cache does not exist. * Use an explicit cr construct: {code} datagrid: - viewname1: basecachename - viewname2 ... {code} where the view name would need to be fully qualified and base cache name would be manipulated to account for multiple deployments. * Or require something similar in DDL - by reusing the MATERIALIZATION_TARGET property (as an unqualfied name) or a new property that indicates the cache name to use. That simplifies the parsing to just that property key/value. This would require some additional logic in the codegen plugin more than likely. * Have the operator run a Java "vdb service" pod that provides a rest interface for getting vdb information from submitted ddl. A general thought is that we'll need to default to transactional caches. I'd also like to have it spelled out the various creation / deletion scenarios we are proposing to support. It looks like so far we have: teiid-cache-store indicates a cache store to be used by all dv in the namespace vdb-cache-store indicates a cache store to be used by all deployments of the given vdb ??? Maybe a table of who creates/destroys the secret, the cluster, and the caches. -- This message was sent by Atlassian Jira (v7.13.8#713008)