[
https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug...
]
Ramesh Reddy commented on TEIIDSB-170:
--------------------------------------
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.
Currently, with Regex I did try to capture the context, but yes a full parser of these
multiple statements is probably a better way to do 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.
This is more to do with deletion, so IMO this does not help
Use an explicit cr construct:
Do not like this, IMO the regex has a better chance than this.
by reusing the MATERIALIZATION_TARGET property
This will work actually, this directly represents the cache name. I am ok with this. This
is the most simple one.
Maybe a table of who creates/destroys the secret, the cluster, and
the caches.
| Secret Name | Owner (who creates cluster) | "Create" Key in Secret |
On VDB delete | Cluster Shared |
| teiid-cache-store | User | NO|caches removed (not currently) | Yes, across all vdbs
and their versions |
| {{vdb}}-cache-store| User | NO| caches removed (not currently) | No, only for the
given versions of the VDB |
|{{vdb}}-cache-store| Operator | Yes | Operator removes the cluster | No, only for the
given versions of the VDB |
| none | Operator |Yes| cluster removed | No (only for the given
versions of the VDB |
* in all instances the Infinispan Operator is available, if not available then feature is
turned off and Operator will not generate the materialized model
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)