3:55 p.m.
[
https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug...
]
Ramesh Reddy edited comment on TEIIDSB-170 at 5/11/20 4:54 PM:
---------------------------------------------------------------
Recall that only in the internal materialization case did we not
require the setting of a materialization target name.
It is not the target name, it is internal cache name inside the cluster I am after, target
name is defined on the View, cacheName defined on the Infinispan's foreign table's
options.
In short yes. There should certainly be examples of spinning up a
java process from go.
sigh, I am not questioning if that can be done or not it is a model of execution. I would
need to design a whole new process which may not be efficient at all, one good thing with
the model is I can validate the DDL at the start and stop progress if DDL is invalid.
I don't fully understand what you are advocating here.
You mentioned that schema variance from backward compatibility, I am saying if the user
already writing the DDL based on your strict schema parsing, where this issue arises? If
you are saying older user's DDL fits to that paradigm then I am saying we should not
make that as the decision to choose alternatives designs to accommodate it just yet.
What you think about ignoring all this just going by the just the cache prefix?
was (Author: rareddy):
Recall that only in the internal materialization case did we not
require the setting of a materialization target name.
It is not the target name, it is internal cache name inside the cluster I am after, target
name is defined on the View, cacheName defined on the Infinispan's foreign table's
options.
In short yes. There should certainly be examples of spinning up a
java process from go.
sigh, I am not questioning if that can be done or not it is a model of execution. I would
need to design a whole new process which may be efficient at all, one good thing with the
model is I can validate the DDL at the start and stop progress if DDL is invalid.
I don't fully understand what you are advocating here.
You mentioned that schema variance from backward compatibility, I am saying if the user
already writing the DDL based on your strict schema parsing, where this issue arises? If
you are saying older user's DDL fits to that paradigm then I am saying we should not
make that as the decision to choose alternatives designs to accommodate it just yet.
What you think about ignoring all this just going by the just the cache prefix?
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)
1687
days inactive
1687
days old
0 comments
1 participants
participants (1)
-
Ramesh Reddy (Jira)