[JBoss JIRA] (TEIID-5374) Allow for non-virtual dependent joins to be created over unions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5374?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5374:
----------------------------------
Issue Type: Bug (was: Quality Risk)
> Allow for non-virtual dependent joins to be created over unions
> ----------------------------------------------------------------
>
> Key: TEIID-5374
> URL: https://issues.jboss.org/browse/TEIID-5374
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 11.0
>
>
> A simple structure like:
> {code}
> join
> access
> union
> access
> access
> {code}
> will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join.
> A related issue is that TEIID-5020 introduced a regression when creating a dependent join that is eventually pushed over a union below an access node:
> {code}
> dependent select
> access
> set op
> ..
> {code}
> the logic attempts to move nested dependent select back above the access node - so that only a single dependent predicate exists - based upon the node that is created at a child. However if the child projects a literal into the dependent set criteria, then the result is invalid.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5374) Allow for non-virtual dependent joins to be created over unions
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-5374:
-------------------------------------
Summary: Allow for non-virtual dependent joins to be created over unions
Key: TEIID-5374
URL: https://issues.jboss.org/browse/TEIID-5374
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 11.0
A simple structure like:
join
access
union
access
access
will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5285:
-------------------------------------
Ignoring the performance hit, I could check referential constraints on the relations before deleting or updating.
> Add high-level feature for redirection of updates
> -------------------------------------------------
>
> Key: TEIID-5285
> URL: https://issues.jboss.org/browse/TEIID-5285
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Teiid Spring Boot
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 11.x
>
>
> In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates.
> Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5285:
---------------------------------------
The same suggestion as the schema evolution with microservices - drop any constraints that are in your way while you need to and add them back later.
> Add high-level feature for redirection of updates
> -------------------------------------------------
>
> Key: TEIID-5285
> URL: https://issues.jboss.org/browse/TEIID-5285
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Teiid Spring Boot
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 11.x
>
>
> In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates.
> Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5285:
-------------------------------------
[~shawkins] What is your suggestion to work with table references/relationships in this context?
> Add high-level feature for redirection of updates
> -------------------------------------------------
>
> Key: TEIID-5285
> URL: https://issues.jboss.org/browse/TEIID-5285
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Teiid Spring Boot
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 11.x
>
>
> In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates.
> Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5372) Enhance docker support
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5372:
---------------------------------------
> BTW, for multiple VDBs to work we need to come up with a way to package multiple VDB contents into a single archive and we can devise to deploy them into the engine.
A .vear file instead of an .ear? :)
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5372) Enhance docker support
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5372:
-------------------------------------
I agree that there is not much use in promoting the standalone WildFly based Docker image, as it is not straightforward to configure data sources or any other configuration. Teiid Thorntail implementation does ease the configuration issue.
There is Docker Maven Plugin, that can essentially build images based on the pom file. I am not sure what JDK image it uses. The Fabric8 maven plugin extends the docker maven plugin which can also help generate images for docker and OpenShift deployments.
BTW, for multiple VDBs to work we need to come up with a way to package multiple VDB contents into a single archive and we can devise to deploy them into the engine.
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5353) Prepared Statement params are not pre-evaluated
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5353?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5353:
----------------------------------
Fix Version/s: 10.3.2
> Prepared Statement params are not pre-evaluated
> -----------------------------------------------
>
> Key: TEIID-5353
> URL: https://issues.jboss.org/browse/TEIID-5353
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.12.12.6_4
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 11.0, 10.3.2, 8.12.14.6_4
>
>
> prepared statements, [1] with both criteria as parameters for the prepared statement, the predicates are not evaluated until after batches are pulled. But for [2] if the SEARCH='FALSE' is in the query and not a param, it is pre-evaluated and we only run the one side of the union.
> [1]
> sql = "select * from " +
> "Inventory_Detail" +
> " WHERE SEARCH = (?) and ITEM_ID in (?) OFFSET 0 ROWS FETCH NEXT 500 ROWS ONLY";
> PreparedStatement preparedStatement = conn.prepareStatement(sql);
> preparedStatement.setString(1,"FALSE");
> preparedStatement.setString(2,"1005014161091");
> ResultSet rs = null;
> [2]
> sql = "select * from " +
> "Inventory_Detail" +
> " WHERE SEARCH = 'FALSE' and ITEM_ID in (?) OFFSET 0 ROWS FETCH NEXT 500 ROWS ONLY";
> PreparedStatement preparedStatement = conn.prepareStatement(sql);
> preparedStatement.setString(1,"1005014161091");
> ResultSet rs = null;
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5373) Dependent set created from prepared IN predicate fails
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5373?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5373.
-----------------------------------
Resolution: Done
Added the rewrite / evaluate of the criteria prior to the dependent processing so that the reference replacement happens first.
> Dependent set created from prepared IN predicate fails
> ------------------------------------------------------
>
> Key: TEIID-5373
> URL: https://issues.jboss.org/browse/TEIID-5373
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 11.0, 10.3.2
>
>
> If an IN predicate is used as a dependent set - for example when used as a procedural relational parameter or when it's too large and must be split among source commands - the dependentcriteriaprocessor will throw an assertionerror with "unknown predicate type"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (TEIID-5372) Enhance docker support
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5372:
---------------------------------------
Teiid/JDV usage of docker images splits into several directions:
* Teiid-komodo generated images - https://github.com/teiid/teiid-komodo/tree/2b2b0626c6eee570d9ba7bacfbd4cc...
This has been considered the forward looking work, but is obviously not what you are looking for from a Teiid developer perspective.
* The underlying s2i build - https://github.com/rareddy/teiid-openshift-demo/ shows creating/deploying an image similar to what teiid-komodo is doing
* The teiid community image - which as you note is not really useful in and of itself. Some of the limitations are also discussed on TEIID-5131
* The JDV product docker/openshift images - which are somewhat difficult to configure due to config substitution approach taken by EAP
We need to decide from a community perspective if there's a value in still promoting an image that is based upon the full WildFly integration. If so then a lot of what you are looking to do makes sense. If not, then we need to work on documenting / expanding the s2i build - for example accommodating multiple vdbs.
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months