[JBoss JIRA] (TEIID-5869) Update core-release profile
by Van Halbert (Jira)
Van Halbert created TEIID-5869:
----------------------------------
Summary: Update core-release profile
Key: TEIID-5869
URL: https://issues.redhat.com/browse/TEIID-5869
Project: Teiid
Issue Type: Task
Components: Build/Kits
Affects Versions: 13.x
Reporter: Van Halbert
Assignee: Steven Hawkins
For the 7.6 release, need to update the core-release profile so that it builds all connectors except the following:
- infinispan (removed from 7.6 release)
- sandbox
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-147?page=com.atlassian.jira.plug... ]
Steven Hawkins commented on TEIIDSB-147:
----------------------------------------
Postponing this until there's some clarity around JDG.
> 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.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)
5 years
[JBoss JIRA] (TEIIDSB-151) Update to Teiid 13
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-151?focusedWorklogId=12449643&pa... ]
Steven Hawkins logged work on TEIIDSB-151:
------------------------------------------
Author: Steven Hawkins
Created on: 17/Dec/19 9:18 AM
Start Date: 17/Dec/19 9:18 AM
Worklog Time Spent: 2 hours
Work Description: Also did the 13.0.1 respin of 13.0.0
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 1 hour)
Time Spent: 2 hours
Worklog Id: (was: 12449643)
> Update to Teiid 13
> ------------------
>
> Key: TEIIDSB-151
> URL: https://issues.redhat.com/browse/TEIIDSB-151
> Project: Teiid Spring Boot
> Issue Type: Task
> Components: core
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.3.0
>
> Original Estimate: 1 hour
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Update to Teiid 13
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (TEIID-5867) Support capturing the IMPORT FORIGN DATA in DDLStringVisitor
by Ramesh Reddy (Jira)
Ramesh Reddy created TEIID-5867:
-----------------------------------
Summary: Support capturing the IMPORT FORIGN DATA in DDLStringVisitor
Key: TEIID-5867
URL: https://issues.redhat.com/browse/TEIID-5867
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 13.0
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
In DatabaseStore logic the IMPORT FOREIGN DATA WRAPPER is treated as runtime statements that engine is processing at runtime vs build time representation of the VDB. It is a perfectly valid scenario.
However, when working with VDB building, VDB-Import scenarios we need to capture these as is. can we provide a model in DatabaseStore to capture these in certain situations?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years