[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=14091987#comment-14091987 ] 

Steven Hawkins commented on TEIIDSB-170:
----------------------------------------

> I think it is bad to ask user for more input based because of the your processing model, let's say if we are going to materialize to database, do we need this? no. Then why it should be different for this data grid case.

Whether we need the target name or not is an implementation decision - which isn't really based upon data grid.  Recall that only in the internal materialization case did we not require the setting of a materialization target name.   For all others we did.

if for whatever reason it's too much work (and/or we want to differentiate between in-process internal) to automate around the cache name, regardless of the materialization source type, then it's not too much of a stretch to still require it.

> Unless we want to start writing an Operator in Java I do not how to do that. You are asking spin an external process out to java and execute and capture the results in GO operator.

In short yes.  There should certainly be examples of spinning up a java process from go.  If not it's really easy to imagine a service, probably serverless, that could be provided whatever input ddl and could provide an output of what you need to know.

> I do not agree completely, I suggest we keep thinking this as new development, then how we can bring old customers if any into this model, not the other way around. We can not compromise on the designs for it IMO.

I don't fully understand what you are advocating here.  I'm not suggesting that stuff based upon the latest Teiids isn't somehow a "new/different", but rather that it drags along a lot of baggage because of the architecture - which you are proposing to base the operator on.

> 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)