[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5563:
------------------------------------
Now I'm working on the changes to teiid/teiid.git.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-5563 at 12/10/18 1:37 PM:
--------------------------------------------------------------
All the teiid-core projects have been removed. Now going about cleaning up:
- renaming to teiid-wildfly in the pom's.
- updating README.md
Done, updated to teiid-wildfly.
Before I move this repo to teiid/teiid-wildfly, would like a review to see if there is anything else you would like changed.
was (Author: van.halbert):
All the teiid-core projects have been removed. Now going about cleaning up:
- renaming to teiid-wildfly in the pom's.
- updating README.md
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Work on TEIID-5563 stopped by Van Halbert.
------------------------------------------
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-4498) Generalize subquery batch processing
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4498?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-4498 at 12/10/18 12:57 PM:
------------------------------------------------------------------
To elaborate further, a correlated subquery using equi-join predicates that is guarenteed return 0 or 1 rows for every outer row:
{code}SELECT pm1.g1.*, (select count(*) from pm1.g2 where e1 = pm1.g1.e1) FROM pm1.g1{code}
If subquery unnest default is true, or the mj hint is used then it will be planned as:
{code}select pm1.g1.* cnt from pm1.g1 left outer join (select count(*) cnt from pm1.g2) v where v.e1 = pm1.g1.e1{code}
If not then he existing RuleMergeCriteria logic can create a plan like:
{code}
join
access pm1.g1
access (subplan)
{code}
With some manipulation we get:
{code}
join
access pm1.g1
select (e1 in <dependent values>)
access (subplan)
{code}
However there is little benefit in those plans. The ultimate goal is to have the dependent values pushed.
This gets more complicated in the case of subqueries that may return multiple rows. That would either require using the common table plan show above or altering the join node logic under the left out join case to throw an exception when an outer row matches more than 1 inner row.
was (Author: shawkins):
To elaborate further, a correlated subquery using equi-join predicates that is guarenteed return 0 or 1 rows for every outer row:
{code}SELECT pm1.g1.*, (select count(*) from pm1.g2 where e1 = pm1.g1.e1) FROM pm1.g1{code}
If subquery unnest default is true, or the mj hint is used then it will be planned as:
{code}select pm1.g1.* cnt from pm1.g1 left outer join (select count(*) cnt from pm1.g2) v where pm1.g2.e1 = pm1.g1.e1{code}
If not then he existing RuleMergeCriteria logic can create a plan like:
{code}
join
access pm1.g1
access (subplan)
{code}
With some manipulation we get:
{code}
join
access pm1.g1
select (e1 in <dependent values>)
access (subplan)
{code}
However there is little benefit in those plans. The ultimate goal is to have the dependent values pushed.
This gets more complicated in the case of subqueries that may return multiple rows. That would either require using the common table plan show above or altering the join node logic under the left out join case to throw an exception when an outer row matches more than 1 inner row.
> Generalize subquery batch processing
> ------------------------------------
>
> Key: TEIID-4498
> URL: https://issues.jboss.org/browse/TEIID-4498
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> For subqueries that cannot be unnested, but can be modified to project their correlation, we should have at least batch processing rather than the row by row default.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-4498) Generalize subquery batch processing
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4498?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4498:
---------------------------------------
To elaborate further, a correlated subquery using equi-join predicates that is guarenteed return 0 or 1 rows for every outer row:
{code}SELECT pm1.g1.*, (select count(*) from pm1.g2 where e1 = pm1.g1.e1) FROM pm1.g1{code}
If subquery unnest default is true, or the mj hint is used then it will be planned as:
{code}select pm1.g1.* cnt from pm1.g1 left outer join (select count(*) cnt from pm1.g2) v where pm1.g2.e1 = pm1.g1.e1{code}
If not then he existing RuleMergeCriteria logic can create a plan like:
{code}
join
access pm1.g1
access (subplan)
{code}
With some manipulation we get:
{code}
join
access pm1.g1
select (e1 in <dependent values>)
access (subplan)
{code}
However there is little benefit in those plans. The ultimate goal is to have the dependent values pushed.
This gets more complicated in the case of subqueries that may return multiple rows. That would either require using the common table plan show above or altering the join node logic under the left out join case to throw an exception when an outer row matches more than 1 inner row.
> Generalize subquery batch processing
> ------------------------------------
>
> Key: TEIID-4498
> URL: https://issues.jboss.org/browse/TEIID-4498
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> For subqueries that cannot be unnested, but can be modified to project their correlation, we should have at least batch processing rather than the row by row default.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5563:
------------------------------------
All the teiid-core projects have been removed. Now going about cleaning up:
- renaming to teiid-wildfly in the pom's.
- updating README.md
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-5568) Unit test failure: TestExternalMatViews.testLazyUpdate
by Van Halbert (Jira)
Van Halbert created TEIID-5568:
----------------------------------
Summary: Unit test failure: TestExternalMatViews.testLazyUpdate
Key: TEIID-5568
URL: https://issues.jboss.org/browse/TEIID-5568
Project: Teiid
Issue Type: Bug
Components: Integration Tests
Affects Versions: 12.x
Reporter: Van Halbert
Assignee: Steven Hawkins
Attachments: org.teiid.systemmodel.TestExternalMatViews.txt
testLazyUpdate(org.teiid.systemmodel.TestExternalMatViews) Time elapsed: 1.359 s <<< FAILURE!
java.lang.AssertionError: expected:<3> but was:<1>
See attachment.
Commenting out as TEIID-5563 is being completed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (TEIID-4498) Generalize subquery batch processing
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4498?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4498:
---------------------------------------
I can't make this work easily with the existing logic - it presumes that the subquery will drive a dependent join. With a project subquery we need the reverse. Dependent access nodes currently don't cross subplans. So either I need to rewrite the logic to line the plan or take another approach.
> Generalize subquery batch processing
> ------------------------------------
>
> Key: TEIID-4498
> URL: https://issues.jboss.org/browse/TEIID-4498
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> For subqueries that cannot be unnested, but can be modified to project their correlation, we should have at least batch processing rather than the row by row default.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months