[
https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug...
]
Ramesh Reddy commented on TEIIDSB-170:
--------------------------------------
The approach I will be taking is using a shared Infinispan cluster, where user is
responsible for creating the cluster and providing the connection details in the form of a
`Datasource` properties in the YAML file.
The DataSource name MUST be named `CacheStore`, when Operator runs it will find this
Datastore and generate and run the S2I build, in the maven build then uses
`vdb-codegen-plugin` a generate a new VDB, where all the Views with `materialized = true`
flag without an external materialization target set are picked and copied/cloned into a
separate schema called `materialized` with their fully qualified name. The status table
also gets created in the same schema. A VDB with the name `materialized.ddl` gets
generated and put on the classpath.
Then Operator in the next step will adjust the `application.properties` to point to the
new `materialized.ddl` VDB and loads the VDB.
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 day, 3 hours
Remaining Estimate: 3 days, 5 hours
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)