[
https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi...
]
Ramesh Reddy commented on TEIIDSB-147:
--------------------------------------
Here is my thinking top of my head
Define the expectations for how we'll be configured to hit a JDG
instance - will it be a user exercise to create if it doesn't exist, will we need to
create, will the be a crd strategy for >creation,
we can start with expecting
the JDG instance is available. Yes, once the JDG Operator is available, then we need to
write into DV Operator to instantiate a new cache instance per VDB.
and will it be multi-tenet?
Whether JDG is multi-tenant or not
IMO it should not matter for us, DV cache instance is DV only.
requires replacing the logic that detect failed materialization loads
we can move the materialization management aspect to the Operator to manage, so
failure can be detected
Result set caching needs to directly write batches / results to JDG
rather than relying upon on demand replication.
unless we want to use the buffer
manager with local disk, i would guess replication is not there.
validate external materialization to JDG likely using a transactional
upsert strategy to avoid issues like TEIID-5436
sure
internal materialization replacement needs to based upon something
more like external materialization,
yes, we agreed on this as an incremental
feature.
Caching and materialization changes for JDG / OpenShift
-------------------------------------------------------
Key: TEIIDSB-147
URL:
https://issues.jboss.org/browse/TEIIDSB-147
Project: Teiid Spring Boot
Issue Type: Enhancement
Components: core, OpenShift
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Priority: Major
Fix For: 1.3.0
Started this as a higher level issue in Teiid Spring Boot rather than core Teiid since
the work won't align well to Teiid 13.1, but some things may need addressed there as
well.
Things break down roughly into:
* Single-pod support
** Define the expectations for how we'll be configured to hit a JDG instance - will
it be a user exercise to create if it doesn't exist, will we need to create, will the
be a crd strategy for creation, and will it be multi-tenet? There is also the issue /
assumption of cache sharing based upon vdb name - is that sufficient for now?
** Result set caching needs to directly write batches / results to JDG rather than
relying upon on demand replication.
** validate external materialization to JDG likely using a transactional upsert strategy
to avoid issues like TEIID-5436
* Multi-pod support
** everything from single-pod support
** requires replacing the logic that detect failed materialization loads
** internal materialization replacement needs to based upon something more like external
materialization, but that can be seen as a next step that is turnkey internal
materialization to JDG (little to no user setup required)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)