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

[Steven Hawkins (Jira)]

    [ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075869#comment-14075869 ] 

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.

> need the FQN of the view names to manage the cache when the Infinispan moves to support Cache as CR, that is is the reason for additional parsing.  Otherwise, there are no other good options.

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.

> Automate materialization to JDG
> -------------------------------
>
>                 Key: TEIIDSB-170
>                 URL: https://issues.redhat.com/browse/TEIIDSB-170
>             Project: Teiid Spring Boot
>          Issue Type: Enhancement
>          Components: OpenShift
>            Reporter: Steven Hawkins
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 1.5.0
>
>   Original Estimate: 1 week
>          Time Spent: 1 week, 1 day, 2 hours
>  Remaining Estimate: 0 minutes
>
> Create an internal materialization replacement needs that is turnkey materialization to JDG (little to no user setup required)
> - the operator may create the infinispan cluster if needed
> - the status table and internal representation of the materialization target would be setup automatically
> For the user this would be as simple marking a view as materialized and then it would be populated in jdg upon deployment.  They would not have any concerns with cache naming, status tables, etc.  
> For simplicity the initial version would make a similar assumption to the current internal logic - it is for only a specific vdb.  If the vdb cr is modified, then it's expected that the cache would be recreated.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)