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

[Ramesh Reddy (Jira)]

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

Ramesh Reddy commented on TEIIDSB-170:
--------------------------------------

> They simply are providing a materialization target (or similar) unique name, which is used to drive the base names of the caches created.

I am saying any of these require further user input that that takes away the usability of it as user expected to additional input.

> I'm not looking forward to maintaining two parsers. I'd prefer most of the other solutions to this one.

IMO, one does not need to write a full parser, just enough for the commands, and this is the best option for complete automation. It is not like language features keep extending, these 3 different statements that we are interested in IMO are much static in nature. The problem of cache names is not alone, the issue also exists for maven pom.xml generation, if we want foolproof one this is it.

> 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, 3 days, 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)