[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