[teiid-issues] [JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
Ramesh Reddy (Jira)
issues at jboss.org
Wed Dec 4 13:06:00 EST 2019
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821078#comment-13821078 ]
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)
More information about the teiid-issues
mailing list