[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Ramesh Reddy commented on TEIIDSB-147:
--------------------------------------
I will check if there is PG library in GO, that would be best IMO, if not let's see if we can open up some custom api over actuator?
> 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?
> ** 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)
6 years, 4 months
[JBoss JIRA] (TEIID-5863) Regression with TEIID-5737 and socket properties
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5863:
-------------------------------------
Summary: Regression with TEIID-5737 and socket properties
Key: TEIID-5863
URL: https://issues.jboss.org/browse/TEIID-5863
Project: Teiid
Issue Type: Bug
Components: JDBC Driver
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 13.0, 12.2.2, 12.3.1
TEIID-5737 caused properties to no longer be picked up from the teiid-client-settings.properties file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-147:
----------------------------------------
> Yes, I am thinking Operator should have the scheduler to invoke the materialization actions, based on responses it should keep track of the status.
That suffers from the same issue as the built-in pg materialization - the operator will need a privileged authentication to a pod to make that call. Are you wanting to do this over pg or introduce a new http(s) management service?
> I do not think I follow you on this one, i understand writing batches to JDG.
We're probably saying the same thing. The big issue is writing batches to JDG so that they are available to all pods. It's a smaller issue whether we locally cache those same batches.
> 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?
> ** 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)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Ramesh Reddy commented on TEIIDSB-147:
--------------------------------------
>Can you elaborate on that? Are you saying that the operator will take over as the initiator of materialization actions, time-based refreshes, etc.
Yes, I am thinking Operator should have the scheduler to invoke the materialization actions, based on responses it should keep track of the status. IMO, we can still manage status table or move it to Operator status. One thing to figure out here is how to do pod election so that we can consistently talk to a given pod per the materialization job and detect any restarts.
> Replication isn't so much the concern as distribution.
I do not think I follow you on this one, i understand writing batches to JDG.
> 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?
> ** 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)
6 years, 4 months
[JBoss JIRA] (TEIID-5858) Orcale collation issue with Teiid 9.1.1
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5858?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5858:
---------------------------------------
> Unfortunately, I still get the same error.
Can you provide the plan? It would also help to reproduce this on a later version.
> Orcale collation issue with Teiid 9.1.1
> ---------------------------------------
>
> Key: TEIID-5858
> URL: https://issues.jboss.org/browse/TEIID-5858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.1.1
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Priority: Major
>
> One of customers run into this following error:
> org.teiid.core.TeiidComponentException: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected.
> And they were trying to join multiple oracle databases together. And they are running Teiid 9.1.1
> It seems like I need to change the collation. And I tried to change those values, but it didn't seem to do anything.
> org.teiid.requireTeiidCollation
> org.teiid.collationLocale
> org.teiid.assumeMatchingCollation
> Here is how we create the tables in Oracle:
> CREATE TABLE "DWH_MSFL"."MW_CATEGORY" CREATE TABLE "DWH_MSFL"."MW_CATEGORY" ( "CAT_ID" NUMBER(*,0), "CAT_TITLE" VARCHAR2(255 CHAR), "CAT_TITLE_ORIGIN" VARCHAR2(255 CHAR), "CAT_PAGES" NUMBER(*,0), "CAT_SUBCATS" NUMBER(*,0), "CAT_FILES" NUMBER(*,0) ) SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DWH_MSFL" ;
>
>
> --------------------------
>
> CREATE TABLE "DWH_MSFL"."MW_CATEGORYLINKS" CREATE TABLE "DWH_MSFL"."MW_CATEGORYLINKS" ( "CL_FROM" NUMBER(*,0), "CL_TO" VARCHAR2(255 CHAR), "CL_SORTKEY" VARCHAR2(230 CHAR), "CL_TIMESTAMP" TIMESTAMP (0), "CL_SORTKEY_PREFIX" VARCHAR2(255 CHAR), "CL_COLLATION" VARCHAR2(32 CHAR), "CL_TYPE" VARCHAR2(10 CHAR) ) SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DWH_MSFL" ;
> Notwithstanding, can't the issue somehow be related to categorylinks>category relation or Column-Level Collation (CI_COLLATION)which is set to Uppercase(see insert to categorylinks table in DWH_MSFL.sql). We have an issue exactly with a category and title column(CAT_TITLE)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5858) Orcale collation issue with Teiid 9.1.1
by Ivan Chan (Jira)
[ https://issues.jboss.org/browse/TEIID-5858?page=com.atlassian.jira.plugin... ]
Ivan Chan commented on TEIID-5858:
----------------------------------
I have to set org.teiid.assumeMatchingCollation=false using Java System property and also use EmbeddedConfiguration.getProperties to set property values. Unfortunately, I still get the same error.
> Orcale collation issue with Teiid 9.1.1
> ---------------------------------------
>
> Key: TEIID-5858
> URL: https://issues.jboss.org/browse/TEIID-5858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.1.1
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Priority: Major
>
> One of customers run into this following error:
> org.teiid.core.TeiidComponentException: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected.
> And they were trying to join multiple oracle databases together. And they are running Teiid 9.1.1
> It seems like I need to change the collation. And I tried to change those values, but it didn't seem to do anything.
> org.teiid.requireTeiidCollation
> org.teiid.collationLocale
> org.teiid.assumeMatchingCollation
> Here is how we create the tables in Oracle:
> CREATE TABLE "DWH_MSFL"."MW_CATEGORY" CREATE TABLE "DWH_MSFL"."MW_CATEGORY" ( "CAT_ID" NUMBER(*,0), "CAT_TITLE" VARCHAR2(255 CHAR), "CAT_TITLE_ORIGIN" VARCHAR2(255 CHAR), "CAT_PAGES" NUMBER(*,0), "CAT_SUBCATS" NUMBER(*,0), "CAT_FILES" NUMBER(*,0) ) SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DWH_MSFL" ;
>
>
> --------------------------
>
> CREATE TABLE "DWH_MSFL"."MW_CATEGORYLINKS" CREATE TABLE "DWH_MSFL"."MW_CATEGORYLINKS" ( "CL_FROM" NUMBER(*,0), "CL_TO" VARCHAR2(255 CHAR), "CL_SORTKEY" VARCHAR2(230 CHAR), "CL_TIMESTAMP" TIMESTAMP (0), "CL_SORTKEY_PREFIX" VARCHAR2(255 CHAR), "CL_COLLATION" VARCHAR2(32 CHAR), "CL_TYPE" VARCHAR2(10 CHAR) ) SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DWH_MSFL" ;
> Notwithstanding, can't the issue somehow be related to categorylinks>category relation or Column-Level Collation (CI_COLLATION)which is set to Uppercase(see insert to categorylinks table in DWH_MSFL.sql). We have an issue exactly with a category and title column(CAT_TITLE)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIIDSB-147:
-----------------------------------
Description:
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)
was:
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)
> 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?
> ** 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)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-147:
----------------------------------------
> Whether JDG is multi-tenant or not IMO it should not matter for us, DV cache instance is DV only.
Should have been more specific - I was asking about the relationship between the VDBs and JDG instances.
Based upon the response from the prior the expectation is approximately that admin is responsible for creating a JDG instance. From there we're assuming a cache instance per VDB. Then how JDG manages the cache instances is up to JDG.
> we can move the materialization management aspect to the Operator to manage, so failure can be detected
Can you elaborate on that? Are you saying that the operator will take over as the initiator of materialization actions, time-based refreshes, etc. Or are you saying that the operator will somehow provide the pods with a list of peer pods and their status?
> unless we want to use the buffer manager with local disk, i would guess replication is not there.
I should say that result set caching is more of a multi-pod problem. In a single pod scenario the worst that will happen right now is that the cache won't survive a pod restart - but that's no different than having a single JDV instance today.
Replication isn't so much the concern as distribution - things need to be reimplemented so that the batches are stored in JDG. As it stands the results would not be shared across pods. Whether we also create local entries in the buffermanager (or a local cache) is optional.
> 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)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Ramesh Reddy (Jira)
[ 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)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-147?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-147:
----------------------------------------
[~rareddy] I think there are some existing tasks around this already, but I wanted to create an epic-like issue that we can coordinate things from first.
> 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)
6 years, 4 months