[teiid-issues] [JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift

[Steven Hawkins (Jira)]

     [ https://issues.redhat.com/browse/TEIIDSB-147?focusedWorklogId=12450202&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12450202 ]

Steven Hawkins logged work on TEIIDSB-147:
------------------------------------------

                Author: Steven Hawkins
            Created on: 17/Feb/20 8:11 AM
            Start Date: 17/Feb/20 8:11 AM
    Worklog Time Spent: 1 hour 

Issue Time Tracking
-------------------

    Time Spent: 3 hours  (was: 2 hours)
    Worklog Id:     (was: 12450202)


> Caching and materialization changes for JDG / OpenShift
> -------------------------------------------------------
>
>                 Key: TEIIDSB-147
>                 URL: https://issues.redhat.com/browse/TEIIDSB-147
>             Project: Teiid Spring Boot
>          Issue Type: Enhancement
>          Components: core, OpenShift
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 1.4.0
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>
> 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?
> ** 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
> ** Result set caching needs to directly write batches / results to JDG rather than relying upon on demand replication.
> ** 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)