From issues at jboss.org  Tue Jan  1 20:57:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 1 Jan 2019 20:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.6530.1546394220093@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677378#comment-13677378 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello and happy new year Ramesh,
I am currently quite stuck with getting my OpenUI5 running without batch processing against my Teiid instance. I would therefore like to try to build Olingo myself and replace it in Teiid. Could you please give me some directions on how to do it. I am not very familiar with Java and actually do not know where to start. Thx for your help

Best regards,
 Christoph

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 08:44:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 08:44:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.8481.1546436640278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677562#comment-13677562 ] 

Steven Hawkins commented on TEIID-5581:
---------------------------------------

It appears that it was only an early cs draft of the spec that specified entities with server driven paging:

http://docs.oasis-open.org/odata/odata/v4.0/cs01/part1-protocol/odata-v4.0-cs01-part1-protocol.html

That is then echoed in microsoft and other documentation.

However later revisions switched to use the more general term items:

http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os-part1-protocol.html#_Server-Driven_Paging
http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.html#_Server-Driven_Paging
http://docs.oasis-open.org/odata/odata/v4.01/cs01/part1-protocol/odata-v4.01-cs01-part1-protocol.html#_Toc505771215

So the fix here should be to implement the next link over complex type collections as well.


> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 10:46:01 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 10:46:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.9975.1546443961272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677716#comment-13677716 ] 

Ramesh Reddy commented on TEIID-5545:
-------------------------------------

Happy New Year to you too Christoph.

Basically you want to build Olingo project locally using maven build tool
{code}
/oilingo/mvn clean install
{code}

It will produce the jar files in the `target` directories. You would need to replace the new JAR files with old ones in the WildFly distribution and making sure that the names match. The one caveat is if at all Olingo changed any dependency modules or API then more code on Teiid needs to be modified, this only can be determined after comparing both versions.

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 10:50:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 10:50:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5495) Add support for graphql
	sources
In-Reply-To: <JIRA.12772782.1538589412000@Atlassian.JIRA>
References: <JIRA.12772782.1538589412000@Atlassian.JIRA>
	<JIRA.12772782.1538589412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12772782.1538589412000.10065.1546444200552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677718#comment-13677718 ] 

Steven Hawkins commented on TEIID-5495:
---------------------------------------

[~rareddy] [~rhn-engineering-vhalbert] the expectation here could be as little as something akin to our wsdl support.  Construct a json message, get json back for post-processing.  Ideally though there should be Java clients available that can provide abstract reading of graphql schema and querying.  We could then at least provide a top level entity mapping - an entity would be something that has only optional, non-default arguments.  Something with non-optional or default arguments should be represented as a procedure - or perhaps as a table with access pattern(s).  However at first glance most graphql java frameworks look to expect Java bindings (which could be generated).

> Add support for graphql sources
> -------------------------------
>
>                 Key: TEIID-5495
>                 URL: https://issues.jboss.org/browse/TEIID-5495
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Connector API
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.x
>
>
> We should create translator support for graphql, which will also help us evaluate supporting graphql as a front end as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 12:19:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 12:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.10579.1546449540104@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677753#comment-13677753 ] 

Steven Hawkins commented on TEIID-5581:
---------------------------------------

[~rareddy] It looks like this will need support in olingo - the serializers for complex type collections have no logic for the next link.  Should we pursue an upstream fix, or just throw an exception that indicates the workaround of a procedural relational view instead?

> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 12:34:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 2 Jan 2019 12:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5495) Add support for graphql
	sources
In-Reply-To: <JIRA.12772782.1538589412000@Atlassian.JIRA>
References: <JIRA.12772782.1538589412000@Atlassian.JIRA>
	<JIRA.12772782.1538589412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12772782.1538589412000.10605.1546450440129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5495 stopped by Van Halbert.
------------------------------------------
> Add support for graphql sources
> -------------------------------
>
>                 Key: TEIID-5495
>                 URL: https://issues.jboss.org/browse/TEIID-5495
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Connector API
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.x
>
>
> We should create translator support for graphql, which will also help us evaluate supporting graphql as a front end as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 12:38:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 12:38:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.10622.1546450680075@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677758#comment-13677758 ] 

Ramesh Reddy commented on TEIID-5563:
-------------------------------------

Couple suggestions.

1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.

2) Consider getting rid of the duplicate definition of "groupid" in the projects like "connector-xxxx", that will base their group id to "org.teiid.wildfly.resource-adapters". If we can't do (1) then at least introduce that for resource-adapters module and down.

3) Consider renaming project from "connector-xxxx" to "xxxx-ra" or "ra-xxxx", this along with group-id clearly separate them as WildFly constructs. But this is not really required.

4) org.teiid.translator makes sense, but only for aesthetic reasons. Probably provides more clarity for nomenclature and removes "connectors" altogether which could be duplicate in times with connector, and relieves us from legacy names.

(1) one involves many pom changes, 4 will result in a lot of doc changes I think.

> 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)

From issues at jboss.org  Wed Jan  2 12:44:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 12:44:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.10739.1546451040149@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677763#comment-13677763 ] 

Ramesh Reddy commented on TEIID-5581:
-------------------------------------

[~shawkins] We can pursue the upstream fix, the exception should be a stop-gap measure until we can provide a solution IMO. I believe if we want we can even provide an extended serializer in Teiid code meanwhile.

> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 13:19:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 13:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5495) Add support for graphql
	sources
In-Reply-To: <JIRA.12772782.1538589412000@Atlassian.JIRA>
References: <JIRA.12772782.1538589412000@Atlassian.JIRA>
	<JIRA.12772782.1538589412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12772782.1538589412000.10818.1546453140069@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677770#comment-13677770 ] 

Ramesh Reddy commented on TEIID-5495:
-------------------------------------

agree. I think we can do two levels of support.

1) Basic, supply json and get json back. Current WS translator should suffice that. Need to show some examples.
2) Going custom translator route, we will get a JSON document that has One-2-Many based relationships (mostly). Where this becomes challenging is as you mention input parameter mapping. As these parameters could be just criteria on field or implicit paging techniques or something completely random. The last one is troublesome, but if we take an approach as in the procedure to relational where parameters are added to response (entity) then these can be treated similarly to the criteria.

> Add support for graphql sources
> -------------------------------
>
>                 Key: TEIID-5495
>                 URL: https://issues.jboss.org/browse/TEIID-5495
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Connector API
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.x
>
>
> We should create translator support for graphql, which will also help us evaluate supporting graphql as a front end as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 14:06:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 2 Jan 2019 14:06:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.10842.1546455960065@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677776#comment-13677776 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build (mvn dependency:tree) is in the attached file.

I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0. 

Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?

/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo 

This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?

./client/main/odata-client-api-4.2.0-teiid-5.jar  
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar  
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar       
./server/main/odata-server-core-4.2.0-teiid-5.jar      
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar  
./server/main/teiid-olingo-patches-9.0.6.jar

------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?

Thanks for your help.




> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 14:08:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 2 Jan 2019 14:08:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.10845.1546456080085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677776#comment-13677776 ] 

Christoph John edited comment on TEIID-5545 at 1/2/19 2:07 PM:
---------------------------------------------------------------

Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build I could get with (mvn dependency:tree). Seems I cannot attach files here.

I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0. 

Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?

/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo 

This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?

./client/main/odata-client-api-4.2.0-teiid-5.jar  
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar  
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar       
./server/main/odata-server-core-4.2.0-teiid-5.jar      
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar  
./server/main/teiid-olingo-patches-9.0.6.jar

------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?

Thanks for your help.





was (Author: cjohn001):
Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build (mvn dependency:tree) is in the attached file.

I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0. 

Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?

/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo 

This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?

./client/main/odata-client-api-4.2.0-teiid-5.jar  
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar  
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar       
./server/main/odata-server-core-4.2.0-teiid-5.jar      
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar  
./server/main/teiid-olingo-patches-9.0.6.jar

------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?

Thanks for your help.




> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 14:12:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 14:12:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5582) xml format option is
 ignored by odata crossjoin
In-Reply-To: <JIRA.12785887.1546456287000@Atlassian.JIRA>
References: <JIRA.12785887.1546456287000@Atlassian.JIRA>
	<JIRA.12785887.1546456287805@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785887.1546456287000.10849.1546456320012@Atlassian.JIRA>

Steven Hawkins created TEIID-5582:
-------------------------------------

             Summary: xml format option is ignored by odata crossjoin
                 Key: TEIID-5582
                 URL: https://issues.jboss.org/browse/TEIID-5582
             Project: Teiid
          Issue Type: Bug
          Components: OData
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


Since we have a custom serializer that is only implemented for json, the use of a format option is ignored for cross join queries.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 14:52:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 14:52:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.10879.1546458720064@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677781#comment-13677781 ] 

Ramesh Reddy commented on TEIID-5545:
-------------------------------------

For 9.x Teiid, Olingo from going to 4.2 to 4.5+ I know there are many changes, so simple replacement will not work. You can probably do this only for 11.2 without much hassle. What you show seem as correct list.

Q2: for 4.2 we did some overrides there, so it may not be there in later versions.

Q3: when you look at maven list vs what is in the module.xml file shows as dependencies for each jar/module.

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 15:28:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 15:28:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.10924.1546460880152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677785#comment-13677785 ] 

Steven Hawkins commented on TEIID-5581:
---------------------------------------

There is a pull request https://github.com/teiid/teiid/pull/1115 showing what this looks like with adding some additional logic into the TeiidODataJsonSerializer.  It will have the same issue as TEIID-5582 - so it works only for Json.  Given that there is also a workaround, I've captured https://issues.apache.org/jira/browse/OLINGO-1327 but have not worked it.

> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 16:48:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 2 Jan 2019 16:48:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.10977.1546465680093@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677792#comment-13677792 ] 

Steven Hawkins commented on TEIID-5563:
---------------------------------------

> (1) one involves many pom changes, 4 will result in a lot of doc changes I think.

We can do this in two phases if that makes sense - Teiid 12 reorg and propose new module names, then change things in 13.  The only things that have actually changed in the coordinates at this point are the wildfly kit artifacts. 

> 1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.

This for example will look like org.teiid.wildfly:teiid-wildfly-admin

> 3) Consider renaming project from "connector-xxxx" to "xxxx-ra" or "ra-xxxx", this along with group-id clearly separate them as WildFly constructs. But this is not really required.

I'm fine with leaving them as they are - especially if we do 4.  Connector is the common name for resource adapter.

> 4) org.teiid.translator makes sense, but only for aesthetic reasons. Probably provides more clarity for nomenclature and removes "connectors" altogether which could be duplicate in times with connector, and relieves us from legacy names.

Yes this is the change that clarifies things the most.



> 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)

From issues at jboss.org  Wed Jan  2 17:32:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 2 Jan 2019 17:32:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.11064.1546468320132@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677797#comment-13677797 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello Ramesh,
as things again do not seem to get trivial, I thought the Jira here might be the wrong place to proceed with the discussion. I therefore opened a new topic here. Please have a look at it. 

https://developer.jboss.org/message/987212#987212

Maybe the first topic regarding Teiid 9.x and Olingo 4.2 is more easy to solve than I thought

Regarding Q2: In Teiid 11 also such a patch file teiid-olingo-patches-11.2.0.jar exists. Do you think this can be safely ignored? Should I leave it in or remove it from the modules.xml?

Q3: The modules xml unfortuntely says only what dependencies are there, but not in which version numbers. I assume this is important as well, or am I wrong with this assumption?

    <dependencies>
        <module name="javax.api"/>
        <module name="javax.servlet.api"/>
        <module name="javax.xml.stream.api"/>
        <module name="org.apache.httpcomponents"/>        
        <module name="com.fasterxml.jackson.core.jackson-core"/>
        <module name="com.fasterxml.jackson.core.jackson-annotations"/>
        <module name="com.fasterxml.jackson.core.jackson-databind"/>
        <module name="com.fasterxml.aalto-xml"/>
        <module name="org.apache.olingo.commons"/>
        <module name="org.apache.commons.codec"/>
    </dependencies>



> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 18:08:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 2 Jan 2019 18:08:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.11095.1546470480070@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677801#comment-13677801 ] 

Ramesh Reddy commented on TEIID-5545:
-------------------------------------

If you want the Teiid 9.x working the simplest is to grab the Olingo 4.2 and apply my fix on top of it locally on your code and use that. I did not think of that before ;)

Q2) Yes, you can ignore patches. I do not see any code there.

Q3) if we not changing the versions i.e working with 4.2 on the Teiid 9.x, 4.5 on the 11.x you do not need to mess with any dependencies.

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  2 18:42:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 2 Jan 2019 18:42:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.11164.1546472520075@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677808#comment-13677808 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello Ramesh,
thank you very much for your help. I was also thinking to complicated :) As I have everything in containers already it is quite easy to have two instances of the server running in parallel. Hence I will only patch the 11.x version for the moment.

Regarding Q2: Should I let the patch file in, or should I remove it from modules.xml? If I understand you correctly it should not matter and both options are good to go?

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 03:25:00 2019
From: issues at jboss.org (Colin Mondesir (Jira))
Date: Thu, 3 Jan 2019 03:25:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5580) Support: MongoDB 4.0
In-Reply-To: <JIRA.12785455.1545319817000@Atlassian.JIRA>
References: <JIRA.12785455.1545319817000@Atlassian.JIRA>
	<JIRA.12785455.1545319817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785455.1545319817000.12341.1546503900154@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colin Mondesir updated TEIID-5580:
----------------------------------


> Support: MongoDB 4.0
> --------------------
>
>                 Key: TEIID-5580
>                 URL: https://issues.jboss.org/browse/TEIID-5580
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> According to the MongoDB 4.0  docs [1] the minimum driver version required is 3.80 Currently Teiid 8.12 is using 2.13
> 1 https://docs.mongodb.com/manual/release-notes/4.0/#drivers



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 06:26:00 2019
From: issues at jboss.org (Colin Mondesir (Jira))
Date: Thu, 3 Jan 2019 06:26:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5583) Provide ability to monitor
 how much memory matviews are using
In-Reply-To: <JIRA.12785931.1546514706000@Atlassian.JIRA>
References: <JIRA.12785931.1546514706000@Atlassian.JIRA>
	<JIRA.12785931.1546514706868@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785931.1546514706000.13408.1546514760164@Atlassian.JIRA>

Colin Mondesir created TEIID-5583:
-------------------------------------

             Summary: Provide ability to monitor how much memory matviews are using
                 Key: TEIID-5583
                 URL: https://issues.jboss.org/browse/TEIID-5583
             Project: Teiid
          Issue Type: Enhancement
            Reporter: Colin Mondesir
            Assignee: Steven Hawkins


In the docs it says "Internal materialization (and temp tables in general) have memory overhead for each page. A rough guideline is that there can be 100 million rows in all materialized tables across all VDBs for every gigabyte of heap."

But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 07:53:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 3 Jan 2019 07:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5577) Create clean dependencies
	/ separate boms
In-Reply-To: <JIRA.12785109.1545138894000@Atlassian.JIRA>
References: <JIRA.12785109.1545138894000@Atlassian.JIRA>
	<JIRA.12785109.1545138894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785109.1545138894000.13763.1546519980491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert closed TEIID-5577.
------------------------------
    Resolution: Duplicate Issue


This change was incorporated with the TEIID-5563 changes.

> Create clean dependencies / separate boms
> -----------------------------------------
>
>                 Key: TEIID-5577
>                 URL: https://issues.jboss.org/browse/TEIID-5577
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.  
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc.  We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 07:54:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 3 Jan 2019 07:54:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2052) Add Problem/Resolution to
 query problem using the query plan
In-Reply-To: <JIRA.12466710.1337269718000@Atlassian.JIRA>
References: <JIRA.12466710.1337269718000@Atlassian.JIRA>
	<JIRA.12466710.1337269718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466710.1337269718000.13780.1546520040249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-2052:
----------------------------------

    Assignee: Steven Hawkins  (was: Van Halbert)


> Add Problem/Resolution to query problem using the query plan
> ------------------------------------------------------------
>
>                 Key: TEIID-2052
>                 URL: https://issues.jboss.org/browse/TEIID-2052
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: Documentation
>    Affects Versions: 7.7.1
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Optional
>             Fix For: 12.x
>
>         Attachments: INClauseNotPushedDown.odt
>
>
> Adding content that could be used for query problem resolution.   The initial attachment does the following:
> -  states the query problem (i.e., not pushing down the "IN" clause)
> -  provides the query plan (and debug log) for the query being submitted
> -  provides recommendations for resolving the problem
> -  then indicates how this problem was resolved and what the resulting query plan / debug log
> The idea here is to continue to add other problem scenarios so that this information is really useful for resolving issues.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 07:54:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 3 Jan 2019 07:54:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5491) Provide Benchmarking based
	upon TPC-H
In-Reply-To: <JIRA.12772739.1538576515000@Atlassian.JIRA>
References: <JIRA.12772739.1538576515000@Atlassian.JIRA>
	<JIRA.12772739.1538576515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12772739.1538576515000.13783.1546520040305@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5491:
----------------------------------

    Assignee: Steven Hawkins  (was: Van Halbert)


> Provide Benchmarking based upon TPC-H
> -------------------------------------
>
>                 Key: TEIID-5491
>                 URL: https://issues.jboss.org/browse/TEIID-5491
>             Project: Teiid
>          Issue Type: Task
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>
> We should obtain and provide results around TCP-H 
> from http://www.tpc.org/tpc_documents_current_versions/current_specifications.asp



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 07:57:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 3 Jan 2019 07:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5436) Materialization translator
 infinispan-hotrod inconsistent state
In-Reply-To: <JIRA.12762742.1533132393000@Atlassian.JIRA>
References: <JIRA.12762742.1533132393000@Atlassian.JIRA>
	<JIRA.12762742.1533132393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12762742.1533132393000.13791.1546520220149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert updated TEIID-5436:
-------------------------------
    Fix Version/s: 8.12.16.6_4


> Materialization translator infinispan-hotrod inconsistent state
> ---------------------------------------------------------------
>
>                 Key: TEIID-5436
>                 URL: https://issues.jboss.org/browse/TEIID-5436
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDG Connector, Misc. Connectors
>    Affects Versions: 8.12.12.6_4
>            Reporter: Jan Stastny
>            Assignee: Van Halbert
>            Priority: Critical
>             Fix For: 8.12.16.6_4, 12.x
>
>
> There is an inconsistency between contents of status table and jdg cache when using infinispan-hotrod translator for materialization.
> For a vdb:
> {code:xml}
> <vdb name="teiid5259" version="1">
>     <model name="source">
>         <source connection-jndi-name="java:/jdg71HotrodDS" name="source"
>             translator-name="tr-override" />
>         <metadata type="DDL">
>         <![CDATA[
>             CREATE FOREIGN TABLE a(id integer NOT NULL PRIMARY KEY) OPTIONS (UPDATABLE TRUE, "teiid_ispn:cache" '${primary.cache.name}');
>             CREATE FOREIGN TABLE a_stage(id integer NOT NULL PRIMARY KEY) OPTIONS (UPDATABLE TRUE, "teiid_ispn:cache" '${staging.cache.name}');
>         ]]>
>         </metadata>
>         <metadata type="NATIVE" />
>     </model>
>     <model name="h2Source">
>         <source name="h2Source" translator-name="h2" connection-jndi-name="java:/h2-localhost-9292-ds" />
>     </model>
>     <model name="View" type="VIRTUAL">
>         <metadata type="DDL"><![CDATA[
>             CREATE VIEW mat_a(
>                id integer NOT NULL
>             ) OPTIONS (MATERIALIZED 'TRUE',
>                 MATERIALIZED_TABLE 'source.a',
>                 "teiid_rel:MATERIALIZED_STAGE_TABLE" 'source.a_stage',
>                 "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
>                 "teiid_rel:MATVIEW_STATUS_TABLE" 'h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE',
>                 "teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute source.native(''rename source.a_stage source.a'');',
>                 "teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute source.native(''truncate source.a_stage'');',
>                 "teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION',
>                 "teiid_rel:MATVIEW_TTL" 10000
>             )
>                 AS SELECT 1 UNION ALL SELECT 2;
>          ]]>
>         </metadata>
>     </model>
>     <translator name="tr-override" type="infinispan-hotrod">
>         <property name="SupportsDirectQueryProcedure" value="true"/>
>     </translator>
> </vdb>
> {code}
> I can reach a state when:
> # The status table states LOADED for the view
> # The DATA SRC commands inserting into JDG ended (according to teiid-command log)
> # But consecutive query against the view returns lower count (even though having THROW_EXCEPTION in ONERROR_ACTION property)
> See the attached command log:
> {code}
> 13:59:31,679 INFO  [org.teiid.COMMAND_LOG] (Teiid Timer0) L8MeUp92Tess 	START USER COMMAND:	startTime=2018-03-01 13:59:31.679	requestID=L8MeUp92Tess.0	txID=null	sessionID=L8MeUp92Tess	applicationName=internal	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	sql=execute SYSADMIN.loadMatView('View','mat_a')
> 13:59:31,680 INFO  [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue14) SBqGYWW07OB5 	END USER COMMAND:	endTime=2018-03-01 13:59:31.68	requestID=SBqGYWW07OB5.0	txID=null	sessionID=SBqGYWW07OB5	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:31,715 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue16) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.715	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=SELECT g_0.NAME, g_0.TARGETSCHEMANAME, g_0.TARGETNAME, g_0.VALID, g_0.LOADSTATE, g_0.UPDATED, g_0.CARDINALITY, g_0.LOADNUMBER FROM h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE AS g_0 WHERE (g_0.VDBNAME = 'teiid5259') AND (g_0.VDBVERSION = 1) AND (g_0.SCHEMANAME = 'View') AND (g_0.NAME = 'mat_a')
> 13:59:31,715 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue16) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:31.715	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[SELECT g_0."NAME", g_0."TARGETSCHEMANAME", g_0."TARGETNAME", g_0."VALID", g_0."LOADSTATE", g_0."UPDATED", g_0."CARDINALITY", g_0."LOADNUMBER" FROM "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" AS g_0 WHERE g_0."VDBNAME" = 'teiid5259' AND g_0."VDBVERSION" = 1 AND g_0."SCHEMANAME" = 'View' AND g_0."NAME" = 'mat_a']
> 13:59:31,716 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue17) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.716	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=1071137
> 13:59:31,725 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue18) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.725	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 2, LoadState = 'LOADING', valid = FALSE, Updated = {ts'2018-03-01 13:59:31.719'}, Cardinality = -1 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 1)
> 13:59:31,725 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue18) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:31.725	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 2, "LOADSTATE" = 'LOADING', "VALID" = 0, "UPDATED" = TIMESTAMP '2018-03-01 13:59:31.719', "CARDINALITY" = -1 WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 1]
> 13:59:31,728 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.728	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=1169356
> 13:59:31,731 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.731	requestID=L8MeUp92Tess.0	sourceCommandID=73	executionID=10	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=EXEC source.native('truncate source.a_stage')
> 13:59:31,845 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.845	requestID=uaySHcXyc0o5.0	sourceCommandID=74	executionID=6	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=1	cpuTime(ns)=3558736
> 13:59:31,847 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.847	requestID=uaySHcXyc0o5.0	sourceCommandID=79	executionID=11	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	sql=EXEC source.native('rename source.a_stage source.a')
> 13:59:32,040 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.04	requestID=L8MeUp92Tess.0	sourceCommandID=73	executionID=10	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=0	cpuTime(ns)=1493046
> 13:59:32,047 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.047	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=12	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=INSERT INTO source.a_stage (id) VALUES (1)
> 13:59:32,460 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.46	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=12	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=4783162
> 13:59:32,462 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.462	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=13	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=INSERT INTO source.a_stage (id) VALUES (2)
> 13:59:32,753 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.753	requestID=uaySHcXyc0o5.0	sourceCommandID=79	executionID=11	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=0	cpuTime(ns)=5021072
> 13:59:32,800 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.8	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 1, LoadState = 'LOADED', valid = TRUE, Updated = {ts'2018-03-01 13:59:32.756'}, Cardinality = 2 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 1)
> 13:59:32,801 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:32.801	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 1, "LOADSTATE" = 'LOADED', "VALID" = 1, "UPDATED" = TIMESTAMP '2018-03-01 13:59:32.756', "CARDINALITY" = ? WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 1]
> 13:59:32,804 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.804	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=1	cpuTime(ns)=31050942
> 13:59:32,806 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END USER COMMAND:	endTime=2018-03-01 13:59:32.806	requestID=uaySHcXyc0o5.0	txID=null	sessionID=uaySHcXyc0o5	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:33,005 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.005	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=13	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=4943881
> 13:59:33,014 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:33.014	requestID=L8MeUp92Tess.0	sourceCommandID=79	executionID=15	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=EXEC source.native('rename source.a_stage source.a')
> 13:59:33,723 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.723	requestID=L8MeUp92Tess.0	sourceCommandID=79	executionID=15	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=0	cpuTime(ns)=4426814
> 13:59:33,731 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:33.731	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 2, LoadState = 'LOADED', valid = TRUE, Updated = {ts'2018-03-01 13:59:33.725'}, Cardinality = 2 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 2)
> 13:59:33,732 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:33.732	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 2, "LOADSTATE" = 'LOADED', "VALID" = 1, "UPDATED" = TIMESTAMP '2018-03-01 13:59:33.725', "CARDINALITY" = ? WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 2]
> 13:59:33,737 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.737	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=3747146
> 13:59:33,740 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	END USER COMMAND:	endTime=2018-03-01 13:59:33.74	requestID=L8MeUp92Tess.0	txID=null	sessionID=L8MeUp92Tess	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:35,871 INFO  [org.teiid.COMMAND_LOG] (New I/O worker #2) eP8bDNkHEpSG 	START USER COMMAND:	startTime=2018-03-01 13:59:35.871	requestID=eP8bDNkHEpSG.0	txID=null	sessionID=eP8bDNkHEpSG	applicationName=JDBC	principal=user at teiid-security	vdbName=teiid5259	vdbVersion=1	sql=SELECT COUNT(*) FROM mat_a
> 13:59:35,877 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue22) eP8bDNkHEpSG 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:35.877	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sql=SELECT g_0.VALID, g_0.LOADSTATE FROM h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE AS g_0 WHERE (g_0.VDBNAME = 'teiid5259') AND (g_0.VDBVERSION = 1) AND (g_0.SCHEMANAME = 'View') AND (g_0.NAME = 'mat_a')
> 13:59:35,877 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue22) eP8bDNkHEpSG 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:35.877	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sourceCommand=[SELECT g_0."VALID", g_0."LOADSTATE" FROM "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" AS g_0 WHERE g_0."VDBNAME" = 'teiid5259' AND g_0."VDBVERSION" = 1 AND g_0."SCHEMANAME" = 'View' AND g_0."NAME" = 'mat_a']
> 13:59:35,878 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue23) eP8bDNkHEpSG 	END SRC COMMAND:	endTime=2018-03-01 13:59:35.878	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	finalRowCount=1	cpuTime(ns)=904441
> 13:59:35,879 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue24) eP8bDNkHEpSG 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:35.879	requestID=eP8bDNkHEpSG.0	sourceCommandID=9	executionID=18	txID=null	modelName=source	translatorName=tr-override	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sql=SELECT g_0.id FROM source.a AS g_0
> 13:59:36,326 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue25) eP8bDNkHEpSG 	END SRC COMMAND:	endTime=2018-03-01 13:59:36.326	requestID=eP8bDNkHEpSG.0	sourceCommandID=9	executionID=18	txID=null	modelName=source	translatorName=tr-override	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	finalRowCount=1	cpuTime(ns)=32679662
> 13:59:36,384 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue26) eP8bDNkHEpSG 	END USER COMMAND:	endTime=2018-03-01 13:59:36.384	requestID=eP8bDNkHEpSG.0	txID=null	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 10:58:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 3 Jan 2019 10:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5584) Add/change resource
 limitation to be reactive to out of disk
In-Reply-To: <JIRA.12785970.1546531021000@Atlassian.JIRA>
References: <JIRA.12785970.1546531021000@Atlassian.JIRA>
	<JIRA.12785970.1546531021763@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785970.1546531021000.15533.1546531080044@Atlassian.JIRA>

Steven Hawkins created TEIID-5584:
-------------------------------------

             Summary: Add/change resource limitation to be reactive to out of disk
                 Key: TEIID-5584
                 URL: https://issues.jboss.org/browse/TEIID-5584
             Project: Teiid
          Issue Type: Quality Risk
          Components: Query Engine
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.0


Even with tweaks to the behavior of setting hard limits for a single buffer and all session memory consumption - they are not a great way of dealing with over consumption of resources.  Heap memory usage is already pretty well subdivided based upon reserve limits, the max processing setting, max active plans, etc.  It would be best to simply react to the out of disk event by victimizing the session consuming the most resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 11:17:00 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Thu, 3 Jan 2019 11:17:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5516) Exclude hidden schemas in
	metadata
In-Reply-To: <JIRA.12776177.1540408534000@Atlassian.JIRA>
References: <JIRA.12776177.1540408534000@Atlassian.JIRA>
	<JIRA.12776177.1540408534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776177.1540408534000.15610.1546532220718@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5516:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> Exclude hidden schemas in metadata
> ----------------------------------
>
>                 Key: TEIID-5516
>                 URL: https://issues.jboss.org/browse/TEIID-5516
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: JDBC Driver, Query Engine
>    Affects Versions: 8.12.15.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 8.12.17.6_4
>
>         Attachments: Screen_Shot_2018-10-25_at_14.36.23.png
>
>
> See https://issues.jboss.org/browse/TEIID-2476, now that hidden tables/columns are excluded, customer is requesting that the schemas also be excluded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 11:57:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Thu, 3 Jan 2019 11:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.15840.1546534620148@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678099#comment-13678099 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello Ramesh,
very great news!!!! The Olingo update did work and OpenUI5 is now smoothly running in batch mode, at least my first tests look like this :)
I am wondering, if there might be a chance to get you interested in extending the Olingo behavior to support  the early request feature of OpenUI5 as well. Then the entire OData V4 functionality of OpenUI would be supported.
The early request feature seems to be a HEAD request which is send as soon as the model is instantiated to async cache the metadata file/ files of the service for faster loading of SPA apps. The feature is described here:

https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v4.ODataModel

Search in the constructor for "earlyRequests?".

What I do not know is, if this feature is part of the official OData V4 Standard, or if this is a SAP feature.

Once again, thanks for your help! Seems like I can really build an enterprise quality app with open source components alone :)

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 11:58:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Thu, 3 Jan 2019 11:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.15852.1546534680398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678099#comment-13678099 ] 

Christoph John edited comment on TEIID-5545 at 1/3/19 11:57 AM:
----------------------------------------------------------------

Hello Ramesh,
very great news!!!! The Olingo update did work and OpenUI5 is now smoothly running in batch mode, at least my first tests look like this :)
I am wondering, if there might be a chance to get you interested in extending the Olingo behavior to support  the early request feature of OpenUI5 as well. Then the entire OData V4 functionality of OpenUI would be supported.
The early request feature seems to be a HEAD request which is send as soon as the model is instantiated to async cache the metadata file/ files of the service for faster loading of SPAs. The feature is described here:

https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v4.ODataModel

Search in the constructor for "earlyRequests?".

What I do not know is, if this feature is part of the official OData V4 Standard, or if this is a SAP feature.

Once again, thanks for your help! Seems like I can really build an enterprise quality app with open source components alone :)


was (Author: cjohn001):
Hello Ramesh,
very great news!!!! The Olingo update did work and OpenUI5 is now smoothly running in batch mode, at least my first tests look like this :)
I am wondering, if there might be a chance to get you interested in extending the Olingo behavior to support  the early request feature of OpenUI5 as well. Then the entire OData V4 functionality of OpenUI would be supported.
The early request feature seems to be a HEAD request which is send as soon as the model is instantiated to async cache the metadata file/ files of the service for faster loading of SPA apps. The feature is described here:

https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v4.ODataModel

Search in the constructor for "earlyRequests?".

What I do not know is, if this feature is part of the official OData V4 Standard, or if this is a SAP feature.

Once again, thanks for your help! Seems like I can really build an enterprise quality app with open source components alone :)

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 12:13:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Thu, 3 Jan 2019 12:13:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.15863.1546535580066@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678105#comment-13678105 ] 

Ramesh Reddy commented on TEIID-5545:
-------------------------------------

I do not remember seeing the "earlyRequests" in OData spec, but I could be wrong. Either case, I do not mind supporting it in Teiid if it does not violate the spec in any manner. If you can open up JIRA with complete details of request/response that is OpenUI5 is expecting that would be useful.

>Once again, thanks for your help! Seems like I can really build an enterprise quality app with open source components alone 
Congratulations! yeah, little persistence goes long way. I would love to see a video of your app sometime.



> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 12:19:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Thu, 3 Jan 2019 12:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.15872.1546535940069@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678108#comment-13678108 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Well, hopefully you will soon. My plans are to get it up till end of Q2 :) Once I know that everything is working smoothly in my OpenShift cluster, I will provide a tutorial and share the entire configuration. In the meantime I am getting convinced that the combination Teiid, Keycloak, OpenUI5 and Cordova is a perfect match for each startup :)

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 12:22:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Thu, 3 Jan 2019 12:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.15884.1546536120151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678108#comment-13678108 ] 

Christoph John edited comment on TEIID-5545 at 1/3/19 12:21 PM:
----------------------------------------------------------------

Well, hopefully you will soon. My plans are to get it up till end of Q2 :) Once I know that everything is working smoothly in my OpenShift cluster, I will provide a tutorial and share the entire configuration. In the meantime I am getting convinced that the combination Teiid, Keycloak, OpenUI5 and Cordova is a perfect match for each startup :)

Regarding the earlyRequests I will try to find some more information. Unfortunately from the logs I can only see that OpenUI5 tries to send a HEAD request. As this is not allowed, OpenUI5 simple skips the preload. Hence, I do not know what would come afterwards.


was (Author: cjohn001):
Well, hopefully you will soon. My plans are to get it up till end of Q2 :) Once I know that everything is working smoothly in my OpenShift cluster, I will provide a tutorial and share the entire configuration. In the meantime I am getting convinced that the combination Teiid, Keycloak, OpenUI5 and Cordova is a perfect match for each startup :)

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan  3 12:22:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 3 Jan 2019 12:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5583) Provide ability to monitor
 how much memory matviews are using
In-Reply-To: <JIRA.12785931.1546514707000@Atlassian.JIRA>
References: <JIRA.12785931.1546514707000@Atlassian.JIRA>
	<JIRA.12785931.1546514707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785931.1546514707000.15887.1546536120209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678110#comment-13678110 ] 

Steven Hawkins commented on TEIID-5583:
---------------------------------------

> But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.

Generally you do not need to adjust the heap for materialization.  Only page metadata and the table structures are held in heap memory - the actual data pages are pushed to lower storage tiers as necessary.

>From the linked case it should first be determined what is holding the memory that is causing the OOM exception.

> Provide ability to monitor how much memory matviews are using
> -------------------------------------------------------------
>
>                 Key: TEIID-5583
>                 URL: https://issues.jboss.org/browse/TEIID-5583
>             Project: Teiid
>          Issue Type: Enhancement
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>
> In the docs it says "Internal materialization (and temp tables in general) have memory overhead for each page. A rough guideline is that there can be 100 million rows in all materialized tables across all VDBs for every gigabyte of heap."
> But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 09:45:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 4 Jan 2019 09:45:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.18681.1546613100511@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678419#comment-13678419 ] 

Van Halbert commented on TEIID-5563:
------------------------------------

Now that the wildfly reorg is done, can this be closed and a new one opened to focus on what's to be done next?

> 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)

From issues at jboss.org  Fri Jan  4 09:47:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 09:47:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.18686.1546613220067@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678420#comment-13678420 ] 

Steven Hawkins commented on TEIID-5563:
---------------------------------------

So the proposal for Teiid 12 is to redo the group and some of the artifact names under the wildfly module - they will have a consistent parent, go back to using the term connector, and replace jboss with wildfly where appropriate.

This will affect a limited number of users of Teiid embedded that have followed the teiid embedded examples (which will need updated) that reference the resource adapter jars.

I'm fine if we defer the change to translators group id.

> 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)

From issues at jboss.org  Fri Jan  4 09:49:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 4 Jan 2019 09:49:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.18689.1546613340425@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678421#comment-13678421 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

The 3 plugins indicated above, are defined in the teiid-komodo pom.xml.   So the next step is add those to the teiid project.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 09:50:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 4 Jan 2019 09:50:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.18703.1546613400069@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678421#comment-13678421 ] 

Van Halbert edited comment on TEIID-5521 at 1/4/19 9:49 AM:
------------------------------------------------------------

The 3 plugins indicated above, are defined in the teiid-komodo pom.xml.   So the next step is add those to the teiid project.  Or should we change the parent for Teiid to the basebom?


was (Author: van.halbert):
The 3 plugins indicated above, are defined in the teiid-komodo pom.xml.   So the next step is add those to the teiid project.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 09:59:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 09:59:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.18786.1546613940205@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678426#comment-13678426 ] 

Steven Hawkins commented on TEIID-5521:
---------------------------------------

> Or should we change the parent for Teiid to the basebom?

That's the intent.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 10:32:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 4 Jan 2019 10:32:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.19043.1546615920067@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678448#comment-13678448 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

And due to my never using these plugins before, just realized that teiid-komodo has these turned off.  So I will use this jira for teiid and create another in  teiidtools for komodo.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 10:36:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 4 Jan 2019 10:36:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.19099.1546616160184@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678450#comment-13678450 ] 

Ramesh Reddy commented on TEIID-5563:
-------------------------------------

There is never better timing, since we are in flow I suggest take the plunge :)

> 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)

From issues at jboss.org  Fri Jan  4 13:23:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 13:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.19524.1546626180072@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678503#comment-13678503 ] 

Steven Hawkins commented on TEIID-5581:
---------------------------------------

I went ahead and merged the pr for 12.  This will also be added to 11.2.  [~cmondesir] please link to a bz if you need a further back port.

> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 13:34:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 13:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5585) Insert of a disk backed
 temporary lob into a temp table is un-readable
In-Reply-To: <JIRA.12786138.1546626782000@Atlassian.JIRA>
References: <JIRA.12786138.1546626782000@Atlassian.JIRA>
	<JIRA.12786138.1546626782662@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786138.1546626782000.19527.1546626840028@Atlassian.JIRA>

Steven Hawkins created TEIID-5585:
-------------------------------------

             Summary: Insert of a disk backed temporary lob into a temp table is un-readable
                 Key: TEIID-5585
                 URL: https://issues.jboss.org/browse/TEIID-5585
             Project: Teiid
          Issue Type: Bug
          Components: Query Engine
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.0


This can be reproduced with a script like:

insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
-- will fail
insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));

The #4 clob is unreadable as the backing filestore is removed after insert.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 14:16:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 14:16:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5585) Insert of a disk backed
 temporary lob into a temp table is un-readable
In-Reply-To: <JIRA.12786138.1546626783000@Atlassian.JIRA>
References: <JIRA.12786138.1546626783000@Atlassian.JIRA>
	<JIRA.12786138.1546626783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786138.1546626783000.19574.1546629360027@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5585:
----------------------------------
    Description: 
This can be reproduced with a script like:

insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));
-- will fail
insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5))

The #5 clob is unreadable as the backing filestore is removed after insert.

  was:
This can be reproduced with a script like:

insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
-- will fail
insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));

The #4 clob is unreadable as the backing filestore is removed after insert.



> Insert of a disk backed temporary lob into a temp table is un-readable
> ----------------------------------------------------------------------
>
>                 Key: TEIID-5585
>                 URL: https://issues.jboss.org/browse/TEIID-5585
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> This can be reproduced with a script like:
> insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
> insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
> insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
> insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
> insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));
> -- will fail
> insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5))
> The #5 clob is unreadable as the backing filestore is removed after insert.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 14:44:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 14:44:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5585) Insert of a disk backed
 temporary lob into a temp table is un-readable
In-Reply-To: <JIRA.12786138.1546626783000@Atlassian.JIRA>
References: <JIRA.12786138.1546626783000@Atlassian.JIRA>
	<JIRA.12786138.1546626783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786138.1546626783000.19593.1546631040021@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678515#comment-13678515 ] 

Steven Hawkins commented on TEIID-5585:
---------------------------------------

The issue is actually with the auto-cleanup performed by the CommandContext tracking of created InputStreamFactories - they do not last from one statement to the next.  So we need temporary tables to assume responsibility for any such lobs.

> Insert of a disk backed temporary lob into a temp table is un-readable
> ----------------------------------------------------------------------
>
>                 Key: TEIID-5585
>                 URL: https://issues.jboss.org/browse/TEIID-5585
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> This can be reproduced with a script like:
> insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
> insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
> insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
> insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
> insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));
> -- will fail
> insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5))
> The #5 clob is unreadable as the backing filestore is removed after insert.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan  4 16:20:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 4 Jan 2019 16:20:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5581) No @nextlink for
	virtualized procedure
In-Reply-To: <JIRA.12785567.1545387317000@Atlassian.JIRA>
References: <JIRA.12785567.1545387317000@Atlassian.JIRA>
	<JIRA.12785567.1545387317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785567.1545387317000.19670.1546636800148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5581.
-----------------------------------
    Fix Version/s: 12.0
                   11.2.2
       Resolution: Done


Combined the complex response logic to handle both the procedure and cross join cases.  Also consolidated the next link logic.  Logged a follow on issue for xml formats.

> No @nextlink for virtualized procedure
> --------------------------------------
>
>                 Key: TEIID-5581
>                 URL: https://issues.jboss.org/browse/TEIID-5581
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>         Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 08:08:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 7 Jan 2019 08:08:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5585) Insert of a disk backed
 temporary lob into a temp table is un-readable
In-Reply-To: <JIRA.12786138.1546626783000@Atlassian.JIRA>
References: <JIRA.12786138.1546626783000@Atlassian.JIRA>
	<JIRA.12786138.1546626783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786138.1546626783000.23822.1546866483860@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5585.
-----------------------------------
    Resolution: Done


Changed the auto cleanup tracking to mark lobs as temporary and remove the flag if inserted into a session or high scoped temporary table.  If the lob is removed from the temporary table we are not yet auto cleaning it again.  That is possible, but it would require reference tracking and/or creating copies of the original.

> Insert of a disk backed temporary lob into a temp table is un-readable
> ----------------------------------------------------------------------
>
>                 Key: TEIID-5585
>                 URL: https://issues.jboss.org/browse/TEIID-5585
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> This can be reproduced with a script like:
> insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
> insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
> insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
> insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
> insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));
> -- will fail
> insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5))
> The #5 clob is unreadable as the backing filestore is removed after insert.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 09:18:00 2019
From: issues at jboss.org (RH Bugzilla Integration (Jira))
Date: Mon, 7 Jan 2019 09:18:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-3747) Deploying a .vdb where a
 dynamic vdb has already been deployed, fails due to duplicates
In-Reply-To: <JIRA.12588462.1444408365000@Atlassian.JIRA>
References: <JIRA.12588462.1444408365000@Atlassian.JIRA>
	<JIRA.12588462.1444408365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588462.1444408365000.24407.1546870680999@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678874#comment-13678874 ] 

RH Bugzilla Integration commented on TEIID-3747:
------------------------------------------------

Debi Rieden <drieden at redhat.com> changed the Status of [bug 1270336|https://bugzilla.redhat.com/show_bug.cgi?id=1270336] from ASSIGNED to CLOSED

> Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
> ---------------------------------------------------------------------------------------
>
>                 Key: TEIID-3747
>                 URL: https://issues.jboss.org/browse/TEIID-3747
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.7.1.6_2
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 8.12
>
>
> deployed a dynamic vdb using CLI:   deploy teiidfiles/vdb/portfolio-vdb.xml
> then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service:
> 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 09:58:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 7 Jan 2019 09:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5586) NPE with buffer manager
	error log
In-Reply-To: <JIRA.12786349.1546873075000@Atlassian.JIRA>
References: <JIRA.12786349.1546873075000@Atlassian.JIRA>
	<JIRA.12786349.1546873075543@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786349.1546873075000.25035.1546873080609@Atlassian.JIRA>

Steven Hawkins created TEIID-5586:
-------------------------------------

             Summary: NPE with buffer manager error log
                 Key: TEIID-5586
                 URL: https://issues.jboss.org/browse/TEIID-5586
             Project: Teiid
          Issue Type: Bug
          Components: Query Engine
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.0, 11.2.2


If the BatchManager is asked to describe a null object (already removed), then an NPE is thrown:

https://github.com/teiid/teiid/blob/cb7e4aacab01fbc17e891e5aa25bca1e960adb40/engine/src/main/java/org/teiid/common/buffer/impl/BufferFrontedFileStoreCache.java#L710 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 10:09:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 7 Jan 2019 10:09:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5586) NPE with buffer manager
	error log
In-Reply-To: <JIRA.12786349.1546873076000@Atlassian.JIRA>
References: <JIRA.12786349.1546873076000@Atlassian.JIRA>
	<JIRA.12786349.1546873076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786349.1546873076000.25317.1546873740881@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5586.
-----------------------------------
    Resolution: Done


Updated the logic to check for a null list.

> NPE with buffer manager error log
> ---------------------------------
>
>                 Key: TEIID-5586
>                 URL: https://issues.jboss.org/browse/TEIID-5586
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>
> If the BatchManager is asked to describe a null object (already removed), then an NPE is thrown:
> https://github.com/teiid/teiid/blob/cb7e4aacab01fbc17e891e5aa25bca1e960adb40/engine/src/main/java/org/teiid/common/buffer/impl/BufferFrontedFileStoreCache.java#L710 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 12:22:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 7 Jan 2019 12:22:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't
 accept NVARCHAR type
In-Reply-To: <JIRA.12786388.1546881713000@Atlassian.JIRA>
References: <JIRA.12786388.1546881713000@Atlassian.JIRA>
	<JIRA.12786388.1546881713119@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786388.1546881713000.27101.1546881722323@Atlassian.JIRA>

Steven Hawkins created TEIID-5587:
-------------------------------------

             Summary: Oracle 11 drivers don't accept NVARCHAR type
                 Key: TEIID-5587
                 URL: https://issues.jboss.org/browse/TEIID-5587
             Project: Teiid
          Issue Type: Bug
          Components: JDBC Connector
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.0, 11.2.2


Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like:

{code}
Caused by: java.sql.SQLException: Invalid column type
	at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187)
	at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577)
	at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286)
	at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548)
	at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145)
{code}

We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 12:23:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 7 Jan 2019 12:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't
 accept NVARCHAR type
In-Reply-To: <JIRA.12786388.1546881713000@Atlassian.JIRA>
References: <JIRA.12786388.1546881713000@Atlassian.JIRA>
	<JIRA.12786388.1546881713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786388.1546881713000.27291.1546881780029@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5587:
----------------------------------


> Oracle 11 drivers don't accept NVARCHAR type
> --------------------------------------------
>
>                 Key: TEIID-5587
>                 URL: https://issues.jboss.org/browse/TEIID-5587
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDBC Connector
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>
> Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like:
> {code}
> Caused by: java.sql.SQLException: Invalid column type
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286)
> 	at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548)
> 	at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145)
> {code}
> We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 16:54:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 7 Jan 2019 16:54:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5588) Please add support for
 earlyRequest feature which is for example used in the OpenUI5 library to
 enhance performance in single page apps
In-Reply-To: <JIRA.12786413.1546898012000@Atlassian.JIRA>
References: <JIRA.12786413.1546898012000@Atlassian.JIRA>
	<JIRA.12786413.1546898012904@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786413.1546898012000.28200.1546898040111@Atlassian.JIRA>

Christoph John created TEIID-5588:
-------------------------------------

             Summary: Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps
                 Key: TEIID-5588
                 URL: https://issues.jboss.org/browse/TEIID-5588
             Project: Teiid
          Issue Type: Enhancement
    Affects Versions: 11.2.1
            Reporter: Christoph John
            Assignee: Steven Hawkins


As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.

Thomas Chadzelek, who I assume is a lead developer for the odata v4 model kindly gave me the following information and offered his support if further questions arise:

The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.

Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.

For further questions you can contact him directly by joining the discussion at:

https://github.com/SAP/openui5/issues/2288

Thanks a lot. Let we know if I can support with testing.

Best regards,
 Christoph







--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 16:55:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 7 Jan 2019 16:55:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.28204.1546898100378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679175#comment-13679175 ] 

Christoph John commented on TEIID-5555:
---------------------------------------

Hello Ramesh,
in the meantime I got detailed feedback regarding the earlyRequest feature. I added a Jira issue for it:

https://issues.jboss.org/browse/TEIID-5588

Thanks for having a look at it!

Best regards,
 Christoph

> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Blocker
>             Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 16:58:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 7 Jan 2019 16:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.28214.1546898280118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679175#comment-13679175 ] 

Christoph John edited comment on TEIID-5555 at 1/7/19 4:57 PM:
---------------------------------------------------------------

Sorry, was the wrong issue to which I added this comment. I unfortunately do not know how to delete it  :(


was (Author: cjohn001):
Hello Ramesh,
in the meantime I got detailed feedback regarding the earlyRequest feature. I added a Jira issue for it:

https://issues.jboss.org/browse/TEIID-5588

Thanks for having a look at it!

Best regards,
 Christoph

> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Blocker
>             Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 16:58:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 7 Jan 2019 16:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5545) Odata V4 Batch processing
 does not work as teiid/olingo rejects "Accept: multipart/mixed" request
 header
In-Reply-To: <JIRA.12779946.1542631940000@Atlassian.JIRA>
References: <JIRA.12779946.1542631940000@Atlassian.JIRA>
	<JIRA.12779946.1542631940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779946.1542631940000.28217.1546898280181@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679178#comment-13679178 ] 

Christoph John commented on TEIID-5545:
---------------------------------------

Hello Ramesh,
in the meantime I got detailed feedback regarding the earlyRequest feature. I added a Jira issue for it:

https://issues.jboss.org/browse/TEIID-5588

Thanks for having a look at it!

Best regards,
Christoph

> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5545
>                 URL: https://issues.jboss.org/browse/TEIID-5545
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2
>            Reporter: Christoph John
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
>  Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However, 
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 17:01:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 7 Jan 2019 17:01:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5588) Please add support for
 earlyRequest feature which is for example used in the OpenUI5 library to
 enhance performance in single page apps
In-Reply-To: <JIRA.12786413.1546898013000@Atlassian.JIRA>
References: <JIRA.12786413.1546898013000@Atlassian.JIRA>
	<JIRA.12786413.1546898013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786413.1546898013000.28223.1546898460030@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5588:
----------------------------------
    Description: 
As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.

Thomas Chadzelek, who I assume is a lead developer for the odata v4 model at SAP kindly provided the following information and offered his support in case further questions arise:

The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.

Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.

For further questions you can contact him directly by joining the discussion at:

https://github.com/SAP/openui5/issues/2288

Thanks a lot. Let we know if I can support with testing.

Best regards,
 Christoph





  was:
As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.

Thomas Chadzelek, who I assume is a lead developer for the odata v4 model kindly gave me the following information and offered his support if further questions arise:

The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.

Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.

For further questions you can contact him directly by joining the discussion at:

https://github.com/SAP/openui5/issues/2288

Thanks a lot. Let we know if I can support with testing.

Best regards,
 Christoph







> Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5588
>                 URL: https://issues.jboss.org/browse/TEIID-5588
>             Project: Teiid
>          Issue Type: Enhancement
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Optional
>
> As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.
> Thomas Chadzelek, who I assume is a lead developer for the odata v4 model at SAP kindly provided the following information and offered his support in case further questions arise:
> The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.
> Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.
> For further questions you can contact him directly by joining the discussion at:
> https://github.com/SAP/openui5/issues/2288
> Thanks a lot. Let we know if I can support with testing.
> Best regards,
>  Christoph



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan  7 17:05:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 7 Jan 2019 17:05:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.28232.1546898700426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5555:
--------------------------------
    Comment: was deleted

(was: Sorry, was the wrong issue to which I added this comment. I unfortunately do not know how to delete it  :()


> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Blocker
>             Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 09:42:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 8 Jan 2019 09:42:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.33049.1546958520312@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679491#comment-13679491 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

Issue with olingo-patches.  With the current pom, it errors with:

{code}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-cli) on project teiid-olingo-patches: The packaging for this project did not assign a file to the build artifact ->
{code}

Tried suggestions of running install:install or jar:jar, but with no luck.

So then added a source code place holder so that it would build the jar:  src/main/java/org/teiid/olingo/README.md,   but then it fails with:
{code}
Unused declared dependencies found
{code}
 
I could comment out dependencies and it will build, that is an option.   For now, locally, commenting out olingo-patches and moving on.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 09:54:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 8 Jan 2019 09:54:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.33273.1546959240514@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679503#comment-13679503 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

Have run into the following duplicate issue in several places:

{code}
[WARNING] Found duplicate (but equal) classes in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING]   org.infinispan.util.AbstractDelegatingCollection
[WARNING]   org.infinispan.util.AbstractDelegatingConcurrentMap
[WARNING]   org.infinispan.util.AbstractDelegatingMap
[WARNING]   org.infinispan.util.AbstractDelegatingSet
[WARNING] Found duplicate and different resources in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING]   features.xml
[WARNING] Found duplicate classes/resources in compile classpath.
[WARNING] Found duplicate (but equal) classes in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING]   org.infinispan.util.AbstractDelegatingCollection
[WARNING]   org.infinispan.util.AbstractDelegatingConcurrentMap
[WARNING]   org.infinispan.util.AbstractDelegatingMap
[WARNING]   org.infinispan.util.AbstractDelegatingSet
[WARNING] Found duplicate and different resources in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING]   features.xml
[WARNING] Found duplicate classes/resources in runtime classpath.

{code}

Need to figure out how to resolve this, but for now, in those projects setting property:
{code}
 <basepom.check.skip-duplicate-finder>true</basepom.check.skip-duplicate-finder>
{code}

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 10:31:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 8 Jan 2019 10:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.33753.1546961460497@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679531#comment-13679531 ] 

Van Halbert commented on TEIID-5563:
------------------------------------

Just an fyi:

Java 9 deprecated six modules that contain Java EE APIs:

    java.activation with javax.activation package
    java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
    java.transaction with javax.transaction package
    java.xml.bind with all javax.xml.bind.* packages
    java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
    java.xml.ws.annotation with javax.annotation package


> 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)

From issues at jboss.org  Tue Jan  8 10:33:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 8 Jan 2019 10:33:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.33763.1546961580114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679531#comment-13679531 ] 

Van Halbert edited comment on TEIID-5563 at 1/8/19 10:32 AM:
-------------------------------------------------------------

Just an fyi:

Java 9 deprecated six modules that contain Java EE APIs:

    java.activation with javax.activation package
    java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
    java.transaction with javax.transaction package
    java.xml.bind with all javax.xml.bind.* packages
    java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
    java.xml.ws.annotation with javax.annotation package

helpful thread:  [https://stackoverflow.com/questions/48204141/replacements-for-deprecated-jpms-modules-with-java-ee-apis]


was (Author: van.halbert):
Just an fyi:

Java 9 deprecated six modules that contain Java EE APIs:

    java.activation with javax.activation package
    java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
    java.transaction with javax.transaction package
    java.xml.bind with all javax.xml.bind.* packages
    java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
    java.xml.ws.annotation with javax.annotation package


> 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)

From issues at jboss.org  Tue Jan  8 10:40:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 8 Jan 2019 10:40:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5525) add a flag to revert to
 the prior behavior (TEIID-4557)
In-Reply-To: <JIRA.12777195.1541005683000@Atlassian.JIRA>
References: <JIRA.12777195.1541005683000@Atlassian.JIRA>
	<JIRA.12777195.1541005683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12777195.1541005683000.33806.1546962000322@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679538#comment-13679538 ] 

Steven Hawkins commented on TEIID-5525:
---------------------------------------

Followed up with TEIID-5584 to default enforceSingleMaxBufferSizeEstimate to false upstream as well.  Starting with 12.x we'll initially rely on intelligent session killing - but the user can enable this or the session maximum if they want more proactive enforcement.

> add a flag to revert to the prior behavior (TEIID-4557)
> -------------------------------------------------------
>
>                 Key: TEIID-5525
>                 URL: https://issues.jboss.org/browse/TEIID-5525
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 8.12.14.6_4, 8.12.15.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1, 8.12.17.6_4
>
>
> Several customers are seeing errors[1] after https://issues.jboss.org/browse/TEIID-4557 was implemented and generally have to drop the max-active-plans to 1 for their queries to succeed.  Can a flag be added to revert to the behavior prior to TEIID-4557?
> [1]
> ERROR [org.teiid.PROCESSOR] TEIID30019 Unexpected exception for request rcX003UtoyEg.0: org.teiid.core.TeiidComponentException: TEIID31261 Max estimated size 4,963,628,721 for a single operation/table id 85 has been exceeded.  The server may need to increase the amount of disk or memory available, or decrease the number of max active plans.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:26:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:26:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526078@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35130.1546975560144@Atlassian.JIRA>

Christoph John created TEIID-5589:
-------------------------------------

             Summary: NavigationProperty not working with Teiid odata, results in  TEIID16053 
                 Key: TEIID-5589
                 URL: https://issues.jboss.org/browse/TEIID-5589
             Project: Teiid
          Issue Type: Bug
    Affects Versions: 11.2.1
            Reporter: Christoph John
            Assignee: Steven Hawkins
         Attachments: metadata.xml

Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples below are shown below. My $metaddata.xml file is attached.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:31:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35137.1546975860116@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Attachment: AccountRecord.xml


> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples below are shown below. My $metaddata.xml file is attached.
> I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:33:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:33:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35148.1546975980754@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to be happen. the uuidUser property you can find here.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples below are shown below. My $metaddata.xml file is attached.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to be happen. the uuidUser property you can find here.
> I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:34:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35156.1546976040053@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to be happen. the uuidUser property you can find here.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:35:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35157.1546976100152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. However, what is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 14:35:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 14:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35164.1546976100296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 15:02:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 8 Jan 2019 15:02:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35189.1546977720140@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679646#comment-13679646 ] 

Ramesh Reddy commented on TEIID-5589:
-------------------------------------

Looks to me like a bug in Teiid code.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 15:06:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 15:06:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35195.1546977960072@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679648#comment-13679648 ] 

Christoph John commented on TEIID-5589:
---------------------------------------

Hello Ramesh,
please let me know as soon as this is fixed. I have 3 weeks holiday now and plan to build my app :) I will go on a nightly build as soon is this should be working again.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 15:20:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 8 Jan 2019 15:20:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.35232.1546978800064@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679648#comment-13679648 ] 

Christoph John edited comment on TEIID-5589 at 1/8/19 3:19 PM:
---------------------------------------------------------------

Hello Ramesh,
please let me know as soon as this is fixed. I have 3 weeks holiday now and plan to build my app :) I will go on a nightly build as soon is this should be working again.

Could you replicate the error, or do you need further background info?


was (Author: cjohn001):
Hello Ramesh,
please let me know as soon as this is fixed. I have 3 weeks holiday now and plan to build my app :) I will go on a nightly build as soon is this should be working again.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 15:52:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 8 Jan 2019 15:52:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't
 accept NVARCHAR type
In-Reply-To: <JIRA.12786388.1546881713000@Atlassian.JIRA>
References: <JIRA.12786388.1546881713000@Atlassian.JIRA>
	<JIRA.12786388.1546881713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786388.1546881713000.35248.1546980720041@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5587.
-----------------------------------
    Resolution: Done


Changed the logic to only use the NVARCHAR type when a character is beyond the 255 code point.

> Oracle 11 drivers don't accept NVARCHAR type
> --------------------------------------------
>
>                 Key: TEIID-5587
>                 URL: https://issues.jboss.org/browse/TEIID-5587
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDBC Connector
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>
> Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like:
> {code}
> Caused by: java.sql.SQLException: Invalid column type
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286)
> 	at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548)
> 	at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145)
> {code}
> We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 16:07:00 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 8 Jan 2019 16:07:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5474) NPE on Complex Query with
 Procedure Call in SELECT
In-Reply-To: <JIRA.12769545.1536838926000@Atlassian.JIRA>
References: <JIRA.12769545.1536838926000@Atlassian.JIRA>
	<JIRA.12769545.1536838926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12769545.1536838926000.35278.1546981620270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5474:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> NPE on Complex Query with Procedure Call in SELECT
> --------------------------------------------------
>
>                 Key: TEIID-5474
>                 URL: https://issues.jboss.org/browse/TEIID-5474
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 11.1
>         Environment: teiid-11.1.0 (from 01.09.2018) on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
>            Reporter: dalex dalex
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 11.2, 11.1.1, 11.0.3, 8.12.17.6_4
>
>
> Running the following query:
> {code:sql}
> SELECT 
> (exec "SYSADMIN.logMsg"(
>     "level" => 'INFO',
>     "context" => 'DEBUG.FOO.BAR',
>     "msg" => tccd.bank_account_holder_name)) as something
> FROM 
> (
> 	SELECT c.city AS "bank_account_holder_name"
> 	FROM "adventureworks.address" c
> 	JOIN 
> 	(
> 		select ca.addressid
> 		from "adventureworks.customeraddress" ca
> 	 cross JOIN 
> 	(
> 		WITH latest_exchange_rates AS 
> 		(
> 			SELECT exchange_rate_date AS month_begin
> 			FROM (
> 				SELECT  CURDATE() as exchange_rate_date
> 				)t
> 		)
> 		SELECT DISTINCT dt.month_start AS month_begin
> 		FROM (
> 			CALL views.createDateDimensionsTable(
> 				"startdate" => TIMESTAMPADD(SQL_TSI_MONTH, 1, (SELECT month_begin FROM latest_exchange_rates)),
> 				"enddate" => TIMESTAMPADD(SQL_TSI_YEAR, 15, (SELECT month_begin FROM latest_exchange_rates))
> 			) ) AS dt
> 	) fx
> 	) ci ON ci.addressid = c.addressid
> ) tccd ;;
> {code}
> will throw out the following stacktrace with NPE:
> {code:noformat}
> 2018-09-13 13:35:21,777 ERROR [org.teiid.PROCESSOR] (Worker5_QueryProcessorQueue36) ZvEDctN1yjKY TEIID30019 Unexpected exception for request ZvEDctN1yjKY.15: java.lang.NullPointerExc
> eption
>         at org.teiid.query.optimizer.relational.rules.RuleMergeVirtual.doMerge(RuleMergeVirtual.java:218)
>         at org.teiid.query.optimizer.relational.rules.RuleMergeVirtual.execute(RuleMergeVirtual.java:80)
>         at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:1025)
>         at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:228)
>         at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:179)
>         at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:458)
>         at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
>         at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:672)
>         at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:351)
>         at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
>         at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:285)
>         at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
>         at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
>         at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 19:10:00 2019
From: issues at jboss.org (G. Richard Bellamy (Jira))
Date: Tue, 8 Jan 2019 19:10:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578262@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.35591.1546992600017@Atlassian.JIRA>

G. Richard Bellamy created TEIID-5590:
-----------------------------------------

             Summary: vdb-maven-plugin - version 1.3 breaks build lifecycle
                 Key: TEIID-5590
                 URL: https://issues.jboss.org/browse/TEIID-5590
             Project: Teiid
          Issue Type: Bug
          Components: Build/Kits, VDB
         Environment: {code}
2019-01-08 15:49:30
rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
2019-01-08 15:52:36
rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
Maven home: /opt/maven
Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
2019-01-08 15:52:40
rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-b26)
OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
{code}
            Reporter: G. Richard Bellamy
            Assignee: Barry LaFond


When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
{code}
[INFO] 'package' is a phase corresponding to this plugin:
org.teiid:vdb-maven-plugin:vdb

It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
* validate: Not defined
* initialize: Not defined
* generate-sources: Not defined
* process-sources: Not defined
* generate-resources: Not defined
* process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
* compile: org.apache.maven.plugins:maven-compiler-plugin:compile
* process-classes: Not defined
* generate-test-sources: Not defined
* process-test-sources: Not defined
* generate-test-resources: Not defined
* process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
* test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
* process-test-classes: Not defined
* test: org.apache.maven.plugins:maven-surefire-plugin:test
* prepare-package: Not defined
* package: org.teiid:vdb-maven-plugin:vdb
* pre-integration-test: Not defined
* integration-test: Not defined
* post-integration-test: Not defined
* verify: Not defined
* install: org.apache.maven.plugins:maven-install-plugin:install
* deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
{code}




--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan  8 21:01:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 8 Jan 2019 21:01:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.35624.1546999260117@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679696#comment-13679696 ] 

Ramesh Reddy commented on TEIID-5590:
-------------------------------------

It was taken out explicitly not to process resources as the theses have no significance in .vdb packaged artifact. I wouldn't say it is breaking it, it is skipping. Have you considered other plug in s perhaps for this task?

> vdb-maven-plugin - version 1.3 breaks build lifecycle
> -----------------------------------------------------
>
>                 Key: TEIID-5590
>                 URL: https://issues.jboss.org/browse/TEIID-5590
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits, VDB
>         Environment: {code}
> 2019-01-08 15:49:30
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
> Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
> 2019-01-08 15:52:36
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
> Maven home: /opt/maven
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
> 2019-01-08 15:52:40
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
> openjdk version "1.8.0_192"
> OpenJDK Runtime Environment (build 1.8.0_192-b26)
> OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
> {code}
>            Reporter: G. Richard Bellamy
>            Assignee: Barry LaFond
>            Priority: Major
>
> When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
> {code}
> [INFO] 'package' is a phase corresponding to this plugin:
> org.teiid:vdb-maven-plugin:vdb
> It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
> * validate: Not defined
> * initialize: Not defined
> * generate-sources: Not defined
> * process-sources: Not defined
> * generate-resources: Not defined
> * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
> * compile: org.apache.maven.plugins:maven-compiler-plugin:compile
> * process-classes: Not defined
> * generate-test-sources: Not defined
> * process-test-sources: Not defined
> * generate-test-resources: Not defined
> * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
> * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
> * process-test-classes: Not defined
> * test: org.apache.maven.plugins:maven-surefire-plugin:test
> * prepare-package: Not defined
> * package: org.teiid:vdb-maven-plugin:vdb
> * pre-integration-test: Not defined
> * integration-test: Not defined
> * post-integration-test: Not defined
> * verify: Not defined
> * install: org.apache.maven.plugins:maven-install-plugin:install
> * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 06:57:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 06:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.37543.1547035020419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------------
Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

As I am not sure if the issue derives from the same place in code, I thought I should add this here.

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------------
> Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
> So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> As I am not sure if the issue derives from the same place in code, I thought I should add this here.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 08:53:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 08:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.38300.1547041980073@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Workaround Description: No general workaround found yet. However, what is working for me is to change the primary key from a string value to an integer. I could do this as I have a table with a special case in which uuid are mapped to their internal database counterparts which are IDs of type integer. Note, when using Teiid Designer it was not sufficient for me to to reimport the database source and sync the vdb. I had to create and configure an entirely new vdb to get things working. Might be that I hit another issue here with Teiid Designer.   (was: No workaround found yet)


> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------------
> Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
> So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> As I am not sure if the issue derives from the same place in code, I thought I should add this here.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 08:55:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 08:55:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.38307.1547042100231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Workaround Description: 
No general workaround found yet. However, what is working for me is to change the primary key from a string value to an integer. I could fortunately do this, as I have a special situation with a table which holds uuids mapped to their internal database counterparts which are IDs of type integer. Hence, in my case both columns qualify as primary keys. 
Note, when using Teiid Designer it was not sufficient for me to reimport the database source and sync the vdb. I had to create and configure an entirely new vdb to get things working. Might be that I hit another issue here with Teiid Designer. 

  was:No general workaround found yet. However, what is working for me is to change the primary key from a string value to an integer. I could do this as I have a table with a special case in which uuid are mapped to their internal database counterparts which are IDs of type integer. Note, when using Teiid Designer it was not sufficient for me to to reimport the database source and sync the vdb. I had to create and configure an entirely new vdb to get things working. Might be that I hit another issue here with Teiid Designer. 



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Blocker
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------------
> Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
> So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> As I am not sure if the issue derives from the same place in code, I thought I should add this here.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 08:56:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 08:56:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.38315.1547042160630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Priority: Major  (was: Blocker)


> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------------
> Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
> So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> As I am not sure if the issue derives from the same place in code, I thought I should add this here.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 09:22:00 2019
From: issues at jboss.org (RH Bugzilla Integration (Jira))
Date: Wed, 9 Jan 2019 09:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't
 accept NVARCHAR type
In-Reply-To: <JIRA.12786388.1546881713000@Atlassian.JIRA>
References: <JIRA.12786388.1546881713000@Atlassian.JIRA>
	<JIRA.12786388.1546881713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786388.1546881713000.38576.1547043720453@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679936#comment-13679936 ] 

RH Bugzilla Integration commented on TEIID-5587:
------------------------------------------------

jolee at redhat.com changed the Status of [bug 1664723|https://bugzilla.redhat.com/show_bug.cgi?id=1664723] from NEW to CLOSED

> Oracle 11 drivers don't accept NVARCHAR type
> --------------------------------------------
>
>                 Key: TEIID-5587
>                 URL: https://issues.jboss.org/browse/TEIID-5587
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDBC Connector
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>
> Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like:
> {code}
> Caused by: java.sql.SQLException: Invalid column type
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286)
> 	at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548)
> 	at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145)
> {code}
> We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 09:54:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 9 Jan 2019 09:54:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.38880.1547045641154@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679964#comment-13679964 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

Just an FYI, that the change in bom parent now doesn't like the subprojects using exclusions in their poms.   Those exclusions need to be moved out the the root pom.   I've run into this twice now in translators.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 10:32:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 10:32:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.39227.1547047920121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------------
-Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:--

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

As I am not sure if the issue derives from the same place in code, I thought I should add this here.-

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------------
Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

As I am not sure if the issue derives from the same place in code, I thought I should add this here.



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------------
> -Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
> So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:--
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> As I am not sure if the issue derives from the same place in code, I thought I should add this here.-



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 10:34:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 10:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.39250.1547048040333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph John updated TEIID-5589:
----------------------------------
    Description: 
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------

There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.

  was:
Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 

Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be

<NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>

Here are two example queries which fail with the same error

http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------------
-Update 9.1.19: I need to to add here, that there might be a second bug involved into the observation. It seems, that the error is due to type comparisons. As there was a comparison with Account.uuuiUser in the error message and as my table Account just holds a one to one mapping between uuids and integers which represent database internal IDs, I switched the primary key in the Account table from uuidUser to idProfile in hope to circumvent the bug.  
So my new observation is, when I disable row constraints in which I must have a comparison against uuidUser in the form "Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch hte primary key as mention previously, than I can follow the navigation property. However, as soon as I enable row constraints again I get a similar error message as before:--

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

As I am not sure if the issue derives from the same place in code, I thought I should add this here.-



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 11:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 11:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5591) Update the teiid embedded
	examples
In-Reply-To: <JIRA.12786801.1547050804000@Atlassian.JIRA>
References: <JIRA.12786801.1547050804000@Atlassian.JIRA>
	<JIRA.12786801.1547050804516@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786801.1547050804000.39945.1547050860281@Atlassian.JIRA>

Steven Hawkins created TEIID-5591:
-------------------------------------

             Summary: Update the teiid embedded examples
                 Key: TEIID-5591
                 URL: https://issues.jboss.org/browse/TEIID-5591
             Project: Teiid
          Issue Type: Sub-task
          Components: Embedded
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.0


With the maven coordinate changes the teiid embedded examples should be updated as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 11:24:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 11:24:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.40032.1547051040095@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680034#comment-13680034 ] 

Steven Hawkins commented on TEIID-5563:
---------------------------------------

[~rhn-engineering-vhalbert] on the javax stuff - that was mostly dealt with by the changes to allow for building with java 11.  Anything that was no longer part of the runtime jar is referenced via a maven dependency.  The only lingering issue for me is that we consolidated on the wildfly dependencies for consistency, but should probably switch to their generic equivalents now.  That's called out in the pom as a todo.

> 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)

From issues at jboss.org  Wed Jan  9 11:25:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 11:25:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly
 distribution into their own repo or module
In-Reply-To: <JIRA.12782573.1544023564000@Atlassian.JIRA>
References: <JIRA.12782573.1544023564000@Atlassian.JIRA>
	<JIRA.12782573.1544023564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782573.1544023564000.40035.1547051100247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5563.
-----------------------------------
    Fix Version/s: 12.0
       Resolution: Done


Marking the parent issue as resolved with module name changes to add consistency to the stuff under the wildfly module.  Also updated the admin guide with the migration notes.

> 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
>             Fix For: 12.0
>
>
> 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)

From issues at jboss.org  Wed Jan  9 11:25:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 11:25:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5591) Update the teiid embedded
	examples
In-Reply-To: <JIRA.12786801.1547050805000@Atlassian.JIRA>
References: <JIRA.12786801.1547050805000@Atlassian.JIRA>
	<JIRA.12786801.1547050805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786801.1547050805000.40039.1547051100343@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5591 started by Steven Hawkins.
---------------------------------------------
> Update the teiid embedded examples
> ----------------------------------
>
>                 Key: TEIID-5591
>                 URL: https://issues.jboss.org/browse/TEIID-5591
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Embedded
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> With the maven coordinate changes the teiid embedded examples should be updated as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 12:23:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 12:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5584) Add/change resource
 limitation to be reactive to out of disk
In-Reply-To: <JIRA.12785970.1546531022000@Atlassian.JIRA>
References: <JIRA.12785970.1546531022000@Atlassian.JIRA>
	<JIRA.12785970.1546531022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785970.1546531022000.40984.1547054580147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5584.
-----------------------------------
    Resolution: Done


Added the changes along with tests for the clob and table scenarios.  However we cannot yet guarantee that the current operation even with the termination of other sessions will succeed as to prevent deadlocks we can't fully stop the world when killing and retry.  If that is a common occurrence, then the user can utilize the single operation or session based memory limits.

> Add/change resource limitation to be reactive to out of disk
> ------------------------------------------------------------
>
>                 Key: TEIID-5584
>                 URL: https://issues.jboss.org/browse/TEIID-5584
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Even with tweaks to the behavior of setting hard limits for a single buffer and all session memory consumption - they are not a great way of dealing with over consumption of resources.  Heap memory usage is already pretty well subdivided based upon reserve limits, the max processing setting, max active plans, etc.  It would be best to simply react to the out of disk event by victimizing the session consuming the most resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 14:30:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 9 Jan 2019 14:30:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41346.1547062200091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680109#comment-13680109 ] 

Ramesh Reddy commented on TEIID-5589:
-------------------------------------

Can you post the DDL between your Account and Profile Table? I think either the association between them is incorrect, or reverse navigation is code in the Teiid is wrong. According to the metadata, the association from Profile and Account should be on "idProfile" property, but it selected a PK property "uuidUser"

If in DDL you have like on Profile table

CONSTRAINT FOREIGN KEY fkProfileInProfile (IdProfile) References Account (IdProfile)  --> then is may be wrong as Account's IdProfile is not a Primary Key

whereas if you have this on Account table

CONSTRAINT FOREIGN KEY fkProfileInProfile (IdProfile) References Profile (IdProfile)  

then reverse navigation on Teiid side is the culprit IMO. 

Also, "Profile_fkProfileInProfile" defined is also deriving similar navigation between two entities, that seems to be at odds with above.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 14:46:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 14:46:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41372.1547063160157@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680113#comment-13680113 ] 

Christoph John commented on TEIID-5589:
---------------------------------------

Hello Ramesh,
if have changed my database in the meantime and do not have the original file anymore. I would need a while to change everything again. is the ddl the vdb file you mean?

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 14:59:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 14:59:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41417.1547063940170@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680118#comment-13680118 ] 

Christoph John commented on TEIID-5589:
---------------------------------------

Hello Ramesh,
if have rebuild an example. So here this navigation path fails for example

http://localhost:8080/odata4/test/test/Profile(38)/fkProfileToAccount


CREATE FOREIGN TABLE Account (
	idProfile long NOT NULL AUTO_INCREMENT OPTIONS (ANNOTATION '', NAMEINSOURCE '`idProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	uuidUser string(36) NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`uuidUser`', NATIVE_TYPE 'CHAR'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(uuidUser),
	CONSTRAINT idProfile_UNIQUE UNIQUE(idProfile),
	CONSTRAINT uuidUser_UNIQUE UNIQUE(uuidUser)
) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Account`', UPDATABLE TRUE);

CREATE FOREIGN TABLE Avatar (
	fkProfile long NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	AvatarImg blob(65535) OPTIONS (ANNOTATION '', NAMEINSOURCE '`AvatarImg`', NATIVE_TYPE 'BLOB'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkProfile_UNIQUE UNIQUE(fkProfile),
	CONSTRAINT fkAvatarToAccount FOREIGN KEY(fkProfile) REFERENCES Account (idProfile)
) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Avatar`', UPDATABLE TRUE);

CREATE FOREIGN TABLE BodyWeight (
	idBodyWeight long NOT NULL AUTO_INCREMENT OPTIONS (ANNOTATION 'We need a surrogate key here as Teiid requires a primary key on each table. fkProfile is not unique here as we can will have multiple weight measurements per person. Moreover, combining it with WeightMeasurementDateTime makes the index to compute intensive.', NAMEINSOURCE '`idBodyWeight`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	fkProfile long NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	WeightMeasurementDateTime timestamp NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`WeightMeasurementDateTime`', NATIVE_TYPE 'DATETIME'),
	Weight float NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`Weight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(idBodyWeight),
	CONSTRAINT idBodyWeight_UNIQUE UNIQUE(idBodyWeight),
	CONSTRAINT fkBodyWeightToAccount FOREIGN KEY(fkProfile) REFERENCES Account (idProfile)
) OPTIONS (ANNOTATION '', NAMEINSOURCE '`BodyWeight`', UPDATABLE TRUE);

CREATE FOREIGN TABLE ConfigOptions (
	fkProfile long NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	MUnitWeight string(2) DEFAULT 'kg' OPTIONS (ANNOTATION '', NAMEINSOURCE '`MUnitWeight`', CHAR_OCTET_LENGTH 8, NATIVE_TYPE 'ENUM'),
	MUnitLength string(2) DEFAULT 'cm' OPTIONS (ANNOTATION '', NAMEINSOURCE '`MUnitLength`', CHAR_OCTET_LENGTH 8, NATIVE_TYPE 'ENUM'),
	MUnitEnergy string(4) DEFAULT 'kcal' OPTIONS (ANNOTATION '', NAMEINSOURCE '`MUnitEnergy`', CHAR_OCTET_LENGTH 16, NATIVE_TYPE 'ENUM'),
	MUnitLiquids string(2) DEFAULT 'ml' OPTIONS (ANNOTATION '', NAMEINSOURCE '`MUnitLiquids`', CHAR_OCTET_LENGTH 8, NATIVE_TYPE 'ENUM'),
	MUnitTime string(3) DEFAULT '24h' OPTIONS (ANNOTATION '', NAMEINSOURCE '`MUnitTime`', CHAR_OCTET_LENGTH 12, NATIVE_TYPE 'ENUM'),
	EnableDrinkReminder boolean DEFAULT '0' OPTIONS (ANNOTATION '', NAMEINSOURCE '`EnableDrinkReminder`', NATIVE_TYPE 'BIT'),
	PreferredContryCodeForSearch string(2) DEFAULT 'de' OPTIONS (ANNOTATION '', NAMEINSOURCE '`PreferredContryCodeForSearch`', CHAR_OCTET_LENGTH 8, NATIVE_TYPE 'VARCHAR'),
	EnableInternationalSearch boolean DEFAULT '1' OPTIONS (ANNOTATION '', NAMEINSOURCE '`EnableInternationalSearch`', NATIVE_TYPE 'BIT'),
	NumberOfActiveMeals long DEFAULT '4' OPTIONS (ANNOTATION '', NAMEINSOURCE '`NumberOfActiveMeals`', NATIVE_TYPE 'INT UNSIGNED'),
	Meal1Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal1Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal1StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal1StartTime`', NATIVE_TYPE 'TIME'),
	Meal2Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal2Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal2StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal2StartTime`', NATIVE_TYPE 'TIME'),
	Meal3Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal3Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal3StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal3StartTime`', NATIVE_TYPE 'TIME'),
	Meal4Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal4Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal4StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal4StartTime`', NATIVE_TYPE 'TIME'),
	Meal5Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal5Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal5StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal5StartTime`', NATIVE_TYPE 'TIME'),
	Meal6Name string(45) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal6Name`', CHAR_OCTET_LENGTH 180, NATIVE_TYPE 'VARCHAR'),
	Meal6StartTime time DEFAULT '00:00:00' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Meal6StartTime`', NATIVE_TYPE 'TIME'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkProfile_UNIQUE UNIQUE(fkProfile),
	CONSTRAINT fkConfigOptionsToAccount FOREIGN KEY(fkProfile) REFERENCES Account (idProfile)
) OPTIONS (ANNOTATION '', NAMEINSOURCE '`ConfigOptions`', UPDATABLE TRUE);

CREATE FOREIGN TABLE Profile (
	fkProfile long NOT NULL OPTIONS (ANNOTATION '', NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	BodyHeight float DEFAULT '0' OPTIONS (ANNOTATION '', NAMEINSOURCE '`BodyHeight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	GoalWeight float DEFAULT '0.000' OPTIONS (ANNOTATION '', NAMEINSOURCE '`GoalWeight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	Gender string(1) DEFAULT 'm' OPTIONS (ANNOTATION '', NAMEINSOURCE '`Gender`', CHAR_OCTET_LENGTH 4, NATIVE_TYPE 'ENUM'),
	BirthDate date DEFAULT '1980-01-01' OPTIONS (ANNOTATION '', NAMEINSOURCE '`BirthDate`', NATIVE_TYPE 'DATE'),
	ActivityLevel string(17) DEFAULT 'strActive' OPTIONS (ANNOTATION '', NAMEINSOURCE '`ActivityLevel`', CHAR_OCTET_LENGTH 68, NATIVE_TYPE 'ENUM'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkProfile_UNIQUE UNIQUE(fkProfile),
	CONSTRAINT fkProfileToAccount FOREIGN KEY(fkProfile) REFERENCES Account (idProfile)
) OPTIONS (ANNOTATION '', NAMEINSOURCE '`Profile`', UPDATABLE TRUE);



> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:01:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 15:01:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41434.1547064060423@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680121#comment-13680121 ] 

Christoph John commented on TEIID-5589:
---------------------------------------

If I change the primary key in Account from uuidUser to idProfile. Things are working.

For completeness, the error message

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>

and the $metadata.xml

<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<edmx:Reference Uri="http://localhost:8080/odata4/static/org.teiid.v1.xml">
<edmx:Include Namespace="org.teiid.v1" Alias="teiid"/>
</edmx:Reference>
<edmx:Reference Uri="http://localhost:8080/odata4/static/org.apache.olingo.v1.xml">
<edmx:Include Namespace="org.apache.olingo.v1" Alias="olingo-extensions"/>
</edmx:Reference>
<edmx:DataServices>
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="test.1.test" Alias="test">
<EntityType Name="Account">
<Key>
<PropertyRef Name="uuidUser"/>
</Key>
<Property Name="idProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`idProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="uuidUser" Type="Edm.String" Nullable="false" MaxLength="36">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`uuidUser`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="Avatar_fkAvatarToAccount" Type="test.Avatar" Nullable="false"/>
<NavigationProperty Name="BodyWeight_fkBodyWeightToAccount" Type="Collection(test.BodyWeight)"/>
<NavigationProperty Name="ConfigOptions_fkConfigOptionsToAccount" Type="test.ConfigOptions" Nullable="false"/>
<NavigationProperty Name="Profile_fkProfileToAccount" Type="test.Profile" Nullable="false"/>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Account`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="test.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>
<EntityType Name="Avatar">
<Key>
<PropertyRef Name="fkProfile"/>
</Key>
<Property Name="fkProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`fkProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="AvatarImg" Type="Edm.Stream">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`AvatarImg`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="fkAvatarToAccount" Type="test.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
</NavigationProperty>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Avatar`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="test.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>
<EntityType Name="BodyWeight">
<Key>
<PropertyRef Name="idBodyWeight"/>
</Key>
<Property Name="idBodyWeight" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`idBodyWeight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="fkProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`fkProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="WeightMeasurementDateTime" Type="Edm.DateTimeOffset" Nullable="false" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`WeightMeasurementDateTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Weight" Type="Edm.Single" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Weight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="fkBodyWeightToAccount" Type="test.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
</NavigationProperty>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`BodyWeight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="test.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>
<EntityType Name="ConfigOptions">
<Key>
<PropertyRef Name="fkProfile"/>
</Key>
<Property Name="fkProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`fkProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="MUnitWeight" Type="Edm.String" DefaultValue="kg" MaxLength="2">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`MUnitWeight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="MUnitLength" Type="Edm.String" DefaultValue="cm" MaxLength="2">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`MUnitLength`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="MUnitEnergy" Type="Edm.String" DefaultValue="kcal" MaxLength="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`MUnitEnergy`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="MUnitLiquids" Type="Edm.String" DefaultValue="ml" MaxLength="2">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`MUnitLiquids`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="MUnitTime" Type="Edm.String" DefaultValue="24h" MaxLength="3">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`MUnitTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="EnableDrinkReminder" Type="Edm.Boolean" DefaultValue="0">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`EnableDrinkReminder`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="PreferredContryCodeForSearch" Type="Edm.String" DefaultValue="de" MaxLength="2">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`PreferredContryCodeForSearch`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="EnableInternationalSearch" Type="Edm.Boolean" DefaultValue="1">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`EnableInternationalSearch`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="NumberOfActiveMeals" Type="Edm.Int64" DefaultValue="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`NumberOfActiveMeals`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal1Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal1Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal1StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal1StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal2Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal2Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal2StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal2StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal3Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal3Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal3StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal3StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal4Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal4Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal4StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal4StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal5Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal5Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal5StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal5StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal6Name" Type="Edm.String" MaxLength="45">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal6Name`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Meal6StartTime" Type="Edm.TimeOfDay" DefaultValue="00:00:00" Precision="4">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Meal6StartTime`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="fkConfigOptionsToAccount" Type="test.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
</NavigationProperty>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`ConfigOptions`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="test.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>
<EntityType Name="Profile">
<Key>
<PropertyRef Name="fkProfile"/>
</Key>
<Property Name="fkProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`fkProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="BodyHeight" Type="Edm.Single" DefaultValue="0">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`BodyHeight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="GoalWeight" Type="Edm.Single" DefaultValue="0.000">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`GoalWeight`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="Gender" Type="Edm.String" DefaultValue="m" MaxLength="1">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Gender`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="BirthDate" Type="Edm.Date" DefaultValue="1980-01-01">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`BirthDate`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="ActivityLevel" Type="Edm.String" DefaultValue="strActive" MaxLength="17">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`ActivityLevel`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="fkProfileToAccount" Type="test.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
</NavigationProperty>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Profile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="test.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="test.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>
<Term Name="teiid_rel:ALLOW_MATVIEW_MANAGEMENT" Type="Edm.String" AppliesTo="EntityType EntityType EntityType EntityType EntityType"/>
<Term Name="teiid_rel:MATVIEW_ONERROR_ACTION" Type="Edm.String" AppliesTo="EntityType EntityType EntityType EntityType EntityType"/>
<Term Name="teiid_rel:MATVIEW_SHARE_SCOPE" Type="Edm.String" AppliesTo="EntityType EntityType EntityType EntityType EntityType"/>
<EntityContainer Name="test">
<EntitySet Name="Account" EntityType="test.Account">
<NavigationPropertyBinding Path="Avatar_fkAvatarToAccount" Target="Avatar"/>
<NavigationPropertyBinding Path="BodyWeight_fkBodyWeightToAccount" Target="BodyWeight"/>
<NavigationPropertyBinding Path="ConfigOptions_fkConfigOptionsToAccount" Target="ConfigOptions"/>
<NavigationPropertyBinding Path="Profile_fkProfileToAccount" Target="Profile"/>
</EntitySet>
<EntitySet Name="Avatar" EntityType="test.Avatar">
<NavigationPropertyBinding Path="fkAvatarToAccount" Target="Account"/>
</EntitySet>
<EntitySet Name="BodyWeight" EntityType="test.BodyWeight">
<NavigationPropertyBinding Path="fkBodyWeightToAccount" Target="Account"/>
</EntitySet>
<EntitySet Name="ConfigOptions" EntityType="test.ConfigOptions">
<NavigationPropertyBinding Path="fkConfigOptionsToAccount" Target="Account"/>
</EntitySet>
<EntitySet Name="Profile" EntityType="test.Profile">
<NavigationPropertyBinding Path="fkProfileToAccount" Target="Account"/>
</EntitySet>
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:03:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 9 Jan 2019 15:03:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41438.1547064180139@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680123#comment-13680123 ] 

Ramesh Reddy commented on TEIID-5589:
-------------------------------------

Yes, DDL in the VDB just for those two tables and their relationships.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:06:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 15:06:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41445.1547064360227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680125#comment-13680125 ] 

Christoph John commented on TEIID-5589:
---------------------------------------

Is it not the DDL in the first of my two comments?

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:08:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 15:08:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41452.1547064480218@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680125#comment-13680125 ] 

Christoph John edited comment on TEIID-5589 at 1/9/19 3:07 PM:
---------------------------------------------------------------

Is it not the DDL in the first of my two comments? In case it is not. How can I get it out of the vdb?


was (Author: cjohn001):
Is it not the DDL in the first of my two comments?

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:09:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 9 Jan 2019 15:09:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41458.1547064540089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680109#comment-13680109 ] 

Ramesh Reddy edited comment on TEIID-5589 at 1/9/19 3:08 PM:
-------------------------------------------------------------

Can you post the DDL between your Account and Profile Table? I think either the association between them is incorrect, or reverse navigation is code in the Teiid is wrong. According to the metadata, the association from Profile and Account should be on "idProfile" property, but it selected a PK property "uuidUser"

If in DDL you have like on Profile table

CONSTRAINT FOREIGN KEY fkProfileInProfile (fkProfile) References Account (IdProfile)  --> then is may be wrong as Account's IdProfile is not a Primary Key

whereas if you have this on Account table

CONSTRAINT FOREIGN KEY fkProfileInProfile (IdProfile) References Profile (fkProfile)  

then reverse navigation on Teiid side is the culprit IMO. 

Also, "Profile_fkProfileInProfile" defined is also deriving similar navigation between two entities, that seems to be at odds with above.


was (Author: rareddy):
Can you post the DDL between your Account and Profile Table? I think either the association between them is incorrect, or reverse navigation is code in the Teiid is wrong. According to the metadata, the association from Profile and Account should be on "idProfile" property, but it selected a PK property "uuidUser"

If in DDL you have like on Profile table

CONSTRAINT FOREIGN KEY fkProfileInProfile (IdProfile) References Account (IdProfile)  --> then is may be wrong as Account's IdProfile is not a Primary Key

whereas if you have this on Account table

CONSTRAINT FOREIGN KEY fkProfileInProfile (IdProfile) References Profile (IdProfile)  

then reverse navigation on Teiid side is the culprit IMO. 

Also, "Profile_fkProfileInProfile" defined is also deriving similar navigation between two entities, that seems to be at odds with above.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:13:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 15:13:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5575) Release a new arche-type
	revision
In-Reply-To: <JIRA.12785019.1545068443000@Atlassian.JIRA>
References: <JIRA.12785019.1545068443000@Atlassian.JIRA>
	<JIRA.12785019.1545068443000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785019.1545068443000.41462.1547064780039@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5575.
-----------------------------------
    Resolution: Done


Released a 12.0.0 to match the Teiid 12 reorg.

> Release a new arche-type revision
> ---------------------------------
>
>                 Key: TEIID-5575
>                 URL: https://issues.jboss.org/browse/TEIID-5575
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Tools
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> To account for the the new org.teiid:teiid-resource-spi module the connector archetype needs updated.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:23:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 9 Jan 2019 15:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41465.1547065380083@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680125#comment-13680125 ] 

Christoph John edited comment on TEIID-5589 at 1/9/19 3:22 PM:
---------------------------------------------------------------

Is it not the DDL in the first of my two comments? In case it is not. How can I get it out of the vdb?

>>CONSTRAINT FOREIGN KEY fkProfileInProfile (fkProfile) References Account (IdProfile) --> then is may be wrong as Account's IdProfile is not a Primary Key


IdProfile in Accounts is definitely not a primary key but has just a unique constraint set. Is it a requirement to just create foreign keys for primary keys? In that case this would be an implementation error from my side.


was (Author: cjohn001):
Is it not the DDL in the first of my two comments? In case it is not. How can I get it out of the vdb?

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:42:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 15:42:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41530.1547066520136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5589 started by Steven Hawkins.
---------------------------------------------
> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:42:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 15:42:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41533.1547066520194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5589:
----------------------------------
    Component/s: OData


> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 15:51:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 9 Jan 2019 15:51:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41559.1547067060068@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680132#comment-13680132 ] 

Ramesh Reddy commented on TEIID-5589:
-------------------------------------

Yes, I think Teiid did not take unique based mapping into account in this scenario.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 16:14:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 16:14:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41578.1547068440366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5589.
-----------------------------------
    Fix Version/s: 12.0
                   11.2.2
       Resolution: Done


This is related to TEIID-4852 - it was choosing the correct foreign key, but was always using the pk rather than the referenced key for the foreign key.

> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.2
>
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan  9 16:39:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 9 Jan 2019 16:39:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5589) NavigationProperty not
 working with Teiid odata, results in  TEIID16053
In-Reply-To: <JIRA.12786640.1546975526000@Atlassian.JIRA>
References: <JIRA.12786640.1546975526000@Atlassian.JIRA>
	<JIRA.12786640.1546975526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786640.1546975526000.41674.1547069940078@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5589:
----------------------------------
    Fix Version/s: 11.1.2


> NavigationProperty not working with Teiid odata, results in  TEIID16053 
> ------------------------------------------------------------------------
>
>                 Key: TEIID-5589
>                 URL: https://issues.jboss.org/browse/TEIID-5589
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 11.1.2, 12.0, 11.2.2
>
>         Attachments: AccountRecord.xml, metadata.xml
>
>
> Teiid throws an error in case it tries to follow an odata Navigation property. I tried this by using $expand and also by directly following a path. Two examples are shown below. My $metaddata.xml file is attached, and also a single record from the Account table in which the relevant comparison seems to happen. the uuidUser property you can find here.
> I do not understand the error message. What is not clear to me is the assignment which is mentioned there g1.uuidUser = g0.fkProfile 
> Just for your awareness, uuidUser and fkProfile are different columns of different types that should not be compared in anyway. Maybe this is a hint what is going wrong. I would the relevant NavigationProperty expect to be
> <NavigationProperty Name="fkProfileInProfile" Type="my_nutri_diary.Account" Nullable="false">
> <ReferentialConstraint Property="fkProfile" ReferencedProperty="idProfile"/>
> Here are two example queries which fail with the same error
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkProfileInProfile
> http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInProfile
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID31172</code>
> <message>
> TEIID31172 Could not resolve expressions being compared to a common type excluding character conversions: g1.uuidUser = g0.fkProfile
> </message>
> </error>
> ----------------------
> There might also exist a bug in Teiid Designer, when changing the private key and reimporting the database, the source in Teiid Designer looks as expected. However, a sync of the vdb seems not to work properly. For the workaround described in this ticket, I had to create a new vdb in order to get things to work correctely.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 10 11:46:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 10 Jan 2019 11:46:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Updated or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138713000@Atlassian.JIRA>
References: <JIRA.12787031.1547138713000@Atlassian.JIRA>
	<JIRA.12787031.1547138713509@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138713000.47015.1547138760062@Atlassian.JIRA>

Steven Hawkins created TEIID-5592:
-------------------------------------

             Summary: Updated or deprecate teiid-quickstarts
                 Key: TEIID-5592
                 URL: https://issues.jboss.org/browse/TEIID-5592
             Project: Teiid
          Issue Type: Quality Risk
          Components: Quick Starts
            Reporter: Steven Hawkins
            Assignee: Van Halbert
             Fix For: 12.0


The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 10 16:25:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 10 Jan 2019 16:25:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5591) Update the teiid embedded
	examples
In-Reply-To: <JIRA.12786801.1547050805000@Atlassian.JIRA>
References: <JIRA.12786801.1547050805000@Atlassian.JIRA>
	<JIRA.12786801.1547050805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786801.1547050805000.48025.1547155500250@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5591.
-----------------------------------
    Resolution: Done


Updated the master to version 3.0.0-SNAPSHOT work with teiid 12 snapshot.  Cleaned some of the dependency handling.  Ideally we'd remove most usage of version.teiid and rely on the bom, but not all dependencies are managed.

Created a teiid-10.x and set to 2.0.0-SNAPSHOT for teiid 10/11.

teiid.io will be updated in a separate commit.

> Update the teiid embedded examples
> ----------------------------------
>
>                 Key: TEIID-5591
>                 URL: https://issues.jboss.org/browse/TEIID-5591
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Embedded
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> With the maven coordinate changes the teiid embedded examples should be updated as well.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 10 17:46:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 10 Jan 2019 17:46:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.48224.1547160360102@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680694#comment-13680694 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

I've completed the changes on my branch:  [https://github.com/vhalbert/teiid/tree/teiid-5521

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 10 17:49:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 10 Jan 2019 17:49:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.48228.1547160540253@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680694#comment-13680694 ] 

Van Halbert edited comment on TEIID-5521 at 1/10/19 5:48 PM:
-------------------------------------------------------------

I've completed the changes on my branch:  [https://github.com/vhalbert/teiid/tree/teiid-5521

The following are overrides to the basepom settings so that the project can be built.  Most of these are due to duplicate issues, where multiple jar's in the classpath contain the same files.

[vhalbert at localhost teiid]$ grep -Ril '<basepom'
connectors/accumulo/translator-accumulo/pom.xml
connectors/file/translator-excel/pom.xml
connectors/infinispan/infinispan-api/pom.xml
connectors/infinispan/infinispan-tasks/pom.xml
connectors/infinispan/translator-infinispan-hotrod/pom.xml
connectors/jdbc/translator-hive/pom.xml
connectors/jdbc/translator-jdbc/pom.xml
connectors/jdbc/translator-phoenix/pom.xml
connectors/jdbc/translator-prestodb/pom.xml
connectors/misc/translator-jpa/pom.xml
connectors/odata/translator-odata/pom.xml
connectors/swagger/translator-swagger/pom.xml
eclipselink-platform/pom.xml
olingo/pom.xml
rest-service/pom.xml
runtime/pom.xml




was (Author: van.halbert):
I've completed the changes on my branch:  [https://github.com/vhalbert/teiid/tree/teiid-5521

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 08:25:02 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 08:25:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.50877.1547213102167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680893#comment-13680893 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

If you want, I can create a new jira each duplicate, eg.   Infinispan, PartSupplier.vdb, eclipse jar's,  java.activation related

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 08:31:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 08:31:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213461000@Atlassian.JIRA>
References: <JIRA.12787120.1547213461000@Atlassian.JIRA>
	<JIRA.12787120.1547213461600@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213461000.50943.1547213463560@Atlassian.JIRA>

Steven Hawkins created TEIID-5593:
-------------------------------------

             Summary: Add a Java 11 travis build
                 Key: TEIID-5593
                 URL: https://issues.jboss.org/browse/TEIID-5593
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
            Reporter: Steven Hawkins
             Fix For: 12.1


We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 08:44:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 08:44:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214224000@Atlassian.JIRA>
References: <JIRA.12787122.1547214224000@Atlassian.JIRA>
	<JIRA.12787122.1547214224507@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214224000.51096.1547214241917@Atlassian.JIRA>

Steven Hawkins created TEIID-5594:
-------------------------------------

             Summary: Use generic rather than jboss javax dependencies for teiid core
                 Key: TEIID-5594
                 URL: https://issues.jboss.org/browse/TEIID-5594
             Project: Teiid
          Issue Type: Sub-task
          Components: Build/Kits
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.

{code}
<dependency>
               <groupId>org.jboss.spec.javax.ws.rs</groupId>
               <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
               <version>1.0.1.Final</version>
           </dependency>
           <dependency>
               <groupId>org.jboss.spec.javax.xml.ws</groupId>
               <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
               <version>1.0.0.Final</version>
           </dependency>
           <dependency>
               <groupId>org.jboss.spec.javax.servlet</groupId>
               <artifactId>jboss-servlet-api_3.1_spec</artifactId>
               <version>1.0.2.Final</version>
           </dependency> 
           <dependency>
               <groupId>org.jboss.spec.javax.transaction</groupId>
               <artifactId>jboss-transaction-api_1.2_spec</artifactId>
               <version>1.1.1.Final</version>
            </dependency>       
            <dependency>
               <groupId>org.jboss.spec.javax.xml.bind</groupId>
               <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
               <version>1.0.1.Final</version>
           </dependency>           
            <dependency>
               <groupId>org.slf4j</groupId>
               <artifactId>slf4j-api</artifactId>
               <version>1.7.22.jbossorg-1</version>
            </dependency>
{code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:24:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:24:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.51718.1547216640707@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680944#comment-13680944 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

TEIID-5594 should resolve the javax.activation duplicates?

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:25:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 09:25:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.51745.1547216701774@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5555:
----------------------------------
    Priority: Critical  (was: Blocker)


> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:29:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 09:29:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.51752.1547216940281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680948#comment-13680948 ] 

Steven Hawkins commented on TEIID-5521:
---------------------------------------

Yes.  If you want work TEIID-5594 first, then continue this one.  Also do you want to take TEIID-5593?

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:31:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.51766.1547217060190@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680949#comment-13680949 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

Sure, I'll take both.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:31:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.51769.1547217060391@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5593:
----------------------------------

    Assignee: Van Halbert


> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:31:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.51771.1547217060454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5594:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:35:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5595) Solve the maven duplicate
 PartSupplier.vdb issue
In-Reply-To: <JIRA.12787139.1547217277000@Atlassian.JIRA>
References: <JIRA.12787139.1547217277000@Atlassian.JIRA>
	<JIRA.12787139.1547217277152@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787139.1547217277000.51800.1547217300031@Atlassian.JIRA>

Van Halbert created TEIID-5595:
----------------------------------

             Summary: Solve the maven duplicate PartSupplier.vdb issue
                 Key: TEIID-5595
                 URL: https://issues.jboss.org/browse/TEIID-5595
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
    Affects Versions: 12.x
            Reporter: Van Halbert
            Assignee: Steven Hawkins


When changing to use the basebom, it triggered a duplicate artifiact issue with PartsSupplier.vdb between the metadata project and the connector projects.   If its the exact same vdb, then the connector vdb could be removed.  Otherwise, I would suggest the connectors rename their vdb and fix the related dependent tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 09:35:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 09:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5595) Solve the maven duplicate
 PartSupplier.vdb issue
In-Reply-To: <JIRA.12787139.1547217277000@Atlassian.JIRA>
References: <JIRA.12787139.1547217277000@Atlassian.JIRA>
	<JIRA.12787139.1547217277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787139.1547217277000.51801.1547217300116@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5595:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Solve the maven duplicate PartSupplier.vdb issue
> ------------------------------------------------
>
>                 Key: TEIID-5595
>                 URL: https://issues.jboss.org/browse/TEIID-5595
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Trivial
>
> When changing to use the basebom, it triggered a duplicate artifiact issue with PartsSupplier.vdb between the metadata project and the connector projects.   If its the exact same vdb, then the connector vdb could be removed.  Otherwise, I would suggest the connectors rename their vdb and fix the related dependent tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 10:12:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 10:12:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5436) Materialization translator
 infinispan-hotrod inconsistent state
In-Reply-To: <JIRA.12762742.1533132393000@Atlassian.JIRA>
References: <JIRA.12762742.1533132393000@Atlassian.JIRA>
	<JIRA.12762742.1533132393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12762742.1533132393000.52151.1547219521626@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5436:
----------------------------------
    Fix Version/s: 12.1
                       (was: 12.x)


> Materialization translator infinispan-hotrod inconsistent state
> ---------------------------------------------------------------
>
>                 Key: TEIID-5436
>                 URL: https://issues.jboss.org/browse/TEIID-5436
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDG Connector, Misc. Connectors
>    Affects Versions: 8.12.12.6_4
>            Reporter: Jan Stastny
>            Assignee: Van Halbert
>            Priority: Critical
>             Fix For: 8.12.16.6_4, 12.1
>
>
> There is an inconsistency between contents of status table and jdg cache when using infinispan-hotrod translator for materialization.
> For a vdb:
> {code:xml}
> <vdb name="teiid5259" version="1">
>     <model name="source">
>         <source connection-jndi-name="java:/jdg71HotrodDS" name="source"
>             translator-name="tr-override" />
>         <metadata type="DDL">
>         <![CDATA[
>             CREATE FOREIGN TABLE a(id integer NOT NULL PRIMARY KEY) OPTIONS (UPDATABLE TRUE, "teiid_ispn:cache" '${primary.cache.name}');
>             CREATE FOREIGN TABLE a_stage(id integer NOT NULL PRIMARY KEY) OPTIONS (UPDATABLE TRUE, "teiid_ispn:cache" '${staging.cache.name}');
>         ]]>
>         </metadata>
>         <metadata type="NATIVE" />
>     </model>
>     <model name="h2Source">
>         <source name="h2Source" translator-name="h2" connection-jndi-name="java:/h2-localhost-9292-ds" />
>     </model>
>     <model name="View" type="VIRTUAL">
>         <metadata type="DDL"><![CDATA[
>             CREATE VIEW mat_a(
>                id integer NOT NULL
>             ) OPTIONS (MATERIALIZED 'TRUE',
>                 MATERIALIZED_TABLE 'source.a',
>                 "teiid_rel:MATERIALIZED_STAGE_TABLE" 'source.a_stage',
>                 "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
>                 "teiid_rel:MATVIEW_STATUS_TABLE" 'h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE',
>                 "teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute source.native(''rename source.a_stage source.a'');',
>                 "teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute source.native(''truncate source.a_stage'');',
>                 "teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION',
>                 "teiid_rel:MATVIEW_TTL" 10000
>             )
>                 AS SELECT 1 UNION ALL SELECT 2;
>          ]]>
>         </metadata>
>     </model>
>     <translator name="tr-override" type="infinispan-hotrod">
>         <property name="SupportsDirectQueryProcedure" value="true"/>
>     </translator>
> </vdb>
> {code}
> I can reach a state when:
> # The status table states LOADED for the view
> # The DATA SRC commands inserting into JDG ended (according to teiid-command log)
> # But consecutive query against the view returns lower count (even though having THROW_EXCEPTION in ONERROR_ACTION property)
> See the attached command log:
> {code}
> 13:59:31,679 INFO  [org.teiid.COMMAND_LOG] (Teiid Timer0) L8MeUp92Tess 	START USER COMMAND:	startTime=2018-03-01 13:59:31.679	requestID=L8MeUp92Tess.0	txID=null	sessionID=L8MeUp92Tess	applicationName=internal	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	sql=execute SYSADMIN.loadMatView('View','mat_a')
> 13:59:31,680 INFO  [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue14) SBqGYWW07OB5 	END USER COMMAND:	endTime=2018-03-01 13:59:31.68	requestID=SBqGYWW07OB5.0	txID=null	sessionID=SBqGYWW07OB5	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:31,715 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue16) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.715	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=SELECT g_0.NAME, g_0.TARGETSCHEMANAME, g_0.TARGETNAME, g_0.VALID, g_0.LOADSTATE, g_0.UPDATED, g_0.CARDINALITY, g_0.LOADNUMBER FROM h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE AS g_0 WHERE (g_0.VDBNAME = 'teiid5259') AND (g_0.VDBVERSION = 1) AND (g_0.SCHEMANAME = 'View') AND (g_0.NAME = 'mat_a')
> 13:59:31,715 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue16) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:31.715	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[SELECT g_0."NAME", g_0."TARGETSCHEMANAME", g_0."TARGETNAME", g_0."VALID", g_0."LOADSTATE", g_0."UPDATED", g_0."CARDINALITY", g_0."LOADNUMBER" FROM "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" AS g_0 WHERE g_0."VDBNAME" = 'teiid5259' AND g_0."VDBVERSION" = 1 AND g_0."SCHEMANAME" = 'View' AND g_0."NAME" = 'mat_a']
> 13:59:31,716 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue17) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.716	requestID=L8MeUp92Tess.0	sourceCommandID=70	executionID=8	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=1071137
> 13:59:31,725 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue18) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.725	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 2, LoadState = 'LOADING', valid = FALSE, Updated = {ts'2018-03-01 13:59:31.719'}, Cardinality = -1 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 1)
> 13:59:31,725 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue18) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:31.725	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 2, "LOADSTATE" = 'LOADING', "VALID" = 0, "UPDATED" = TIMESTAMP '2018-03-01 13:59:31.719', "CARDINALITY" = -1 WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 1]
> 13:59:31,728 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.728	requestID=L8MeUp92Tess.0	sourceCommandID=71	executionID=9	txID=null	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=1169356
> 13:59:31,731 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.731	requestID=L8MeUp92Tess.0	sourceCommandID=73	executionID=10	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=EXEC source.native('truncate source.a_stage')
> 13:59:31,845 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:31.845	requestID=uaySHcXyc0o5.0	sourceCommandID=74	executionID=6	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=1	cpuTime(ns)=3558736
> 13:59:31,847 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:31.847	requestID=uaySHcXyc0o5.0	sourceCommandID=79	executionID=11	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	sql=EXEC source.native('rename source.a_stage source.a')
> 13:59:32,040 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.04	requestID=L8MeUp92Tess.0	sourceCommandID=73	executionID=10	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=0	cpuTime(ns)=1493046
> 13:59:32,047 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.047	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=12	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=INSERT INTO source.a_stage (id) VALUES (1)
> 13:59:32,460 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.46	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=12	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=4783162
> 13:59:32,462 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.462	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=13	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=INSERT INTO source.a_stage (id) VALUES (2)
> 13:59:32,753 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.753	requestID=uaySHcXyc0o5.0	sourceCommandID=79	executionID=11	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=0	cpuTime(ns)=5021072
> 13:59:32,800 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:32.8	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 1, LoadState = 'LOADED', valid = TRUE, Updated = {ts'2018-03-01 13:59:32.756'}, Cardinality = 2 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 1)
> 13:59:32,801 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:32.801	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 1, "LOADSTATE" = 'LOADED', "VALID" = 1, "UPDATED" = TIMESTAMP '2018-03-01 13:59:32.756', "CARDINALITY" = ? WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 1]
> 13:59:32,804 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END SRC COMMAND:	endTime=2018-03-01 13:59:32.804	requestID=uaySHcXyc0o5.0	sourceCommandID=80	executionID=14	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:e status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=uaySHcXyc0o5	principal=embedded-async	finalRowCount=1	cpuTime(ns)=31050942
> 13:59:32,806 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue11) uaySHcXyc0o5 	END USER COMMAND:	endTime=2018-03-01 13:59:32.806	requestID=uaySHcXyc0o5.0	txID=null	sessionID=uaySHcXyc0o5	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:33,005 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.005	requestID=L8MeUp92Tess.0	sourceCommandID=74	executionID=13	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=4943881
> 13:59:33,014 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:33.014	requestID=L8MeUp92Tess.0	sourceCommandID=79	executionID=15	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	sql=EXEC source.native('rename source.a_stage source.a')
> 13:59:33,723 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue19) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.723	requestID=L8MeUp92Tess.0	sourceCommandID=79	executionID=15	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=source	translatorName=tr-override	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=0	cpuTime(ns)=4426814
> 13:59:33,731 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:33.731	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sql=UPDATE h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE SET LoadNumber = 2, LoadState = 'LOADED', valid = TRUE, Updated = {ts'2018-03-01 13:59:33.725'}, Cardinality = 2 WHERE (VDBName = 'teiid5259') AND (VDBVersion = 1) AND (schemaName = 'View') AND (Name = 'mat_a') AND (loadNumber = 2)
> 13:59:33,732 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:33.732	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	sourceCommand=[UPDATE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" SET "LOADNUMBER" = 2, "LOADSTATE" = 'LOADED', "VALID" = 1, "UPDATED" = TIMESTAMP '2018-03-01 13:59:33.725', "CARDINALITY" = ? WHERE "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBNAME" = 'teiid5259' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."VDBVERSION" = 1 AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."SCHEMANAME" = 'View' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."NAME" = 'mat_a' AND "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE"."LOADNUMBER" = 2]
> 13:59:33,737 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	END SRC COMMAND:	endTime=2018-03-01 13:59:33.737	requestID=L8MeUp92Tess.0	sourceCommandID=80	executionID=16	txID=TransactionImple < ac, BasicAction: 0:ffff0a2804e2:b3ef2e2:5a97f919:f status: ActionStatus.RUNNING >	modelName=h2Source	translatorName=h2	sessionID=L8MeUp92Tess	principal=embedded-async	finalRowCount=1	cpuTime(ns)=3747146
> 13:59:33,740 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue20) L8MeUp92Tess 	END USER COMMAND:	endTime=2018-03-01 13:59:33.74	requestID=L8MeUp92Tess.0	txID=null	sessionID=L8MeUp92Tess	principal=embedded-async	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> 13:59:35,871 INFO  [org.teiid.COMMAND_LOG] (New I/O worker #2) eP8bDNkHEpSG 	START USER COMMAND:	startTime=2018-03-01 13:59:35.871	requestID=eP8bDNkHEpSG.0	txID=null	sessionID=eP8bDNkHEpSG	applicationName=JDBC	principal=user at teiid-security	vdbName=teiid5259	vdbVersion=1	sql=SELECT COUNT(*) FROM mat_a
> 13:59:35,877 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue22) eP8bDNkHEpSG 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:35.877	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sql=SELECT g_0.VALID, g_0.LOADSTATE FROM h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE AS g_0 WHERE (g_0.VDBNAME = 'teiid5259') AND (g_0.VDBVERSION = 1) AND (g_0.SCHEMANAME = 'View') AND (g_0.NAME = 'mat_a')
> 13:59:35,877 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue22) eP8bDNkHEpSG 	SOURCE SRC COMMAND:	endTime=2018-03-01 13:59:35.877	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sourceCommand=[SELECT g_0."VALID", g_0."LOADSTATE" FROM "DB"."PUBLIC"."DV_MATVIEWS_STATUSTABLE" AS g_0 WHERE g_0."VDBNAME" = 'teiid5259' AND g_0."VDBVERSION" = 1 AND g_0."SCHEMANAME" = 'View' AND g_0."NAME" = 'mat_a']
> 13:59:35,878 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue23) eP8bDNkHEpSG 	END SRC COMMAND:	endTime=2018-03-01 13:59:35.878	requestID=eP8bDNkHEpSG.0	sourceCommandID=6	executionID=17	txID=null	modelName=h2Source	translatorName=h2	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	finalRowCount=1	cpuTime(ns)=904441
> 13:59:35,879 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue24) eP8bDNkHEpSG 	START DATA SRC COMMAND:	startTime=2018-03-01 13:59:35.879	requestID=eP8bDNkHEpSG.0	sourceCommandID=9	executionID=18	txID=null	modelName=source	translatorName=tr-override	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	sql=SELECT g_0.id FROM source.a AS g_0
> 13:59:36,326 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue25) eP8bDNkHEpSG 	END SRC COMMAND:	endTime=2018-03-01 13:59:36.326	requestID=eP8bDNkHEpSG.0	sourceCommandID=9	executionID=18	txID=null	modelName=source	translatorName=tr-override	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	finalRowCount=1	cpuTime(ns)=32679662
> 13:59:36,384 INFO  [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue26) eP8bDNkHEpSG 	END USER COMMAND:	endTime=2018-03-01 13:59:36.384	requestID=eP8bDNkHEpSG.0	txID=null	sessionID=eP8bDNkHEpSG	principal=user at teiid-security	vdbName=teiid5259	vdbVersion=1	finalRowCount=1
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 11:49:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 11 Jan 2019 11:49:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.53673.1547225340415@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681063#comment-13681063 ] 

Ramesh Reddy commented on TEIID-5521:
-------------------------------------

[~vhalbert] Please do not add any dependency scopes like

{code}
<scope>compile</scope>
{code}

anywhere unless you for sure it is only used for that purpose. A wrong one will make embedded apps fail to run at runtime in unexpected ways. Also, I know basepom changes sometimes makes you add the transitive dependencies to make the dependency graph clear, but be sure what add/remove as dependencies as it should not be a lot. Like for example, I am not sure why you added 

{code}
        <dependency>
              <groupId>com.vividsolutions</groupId>
              <artifactId>jts</artifactId>
        </dependency> 	  
{code}

for olingo code. If in doubt, take out dependency that is causing an issue, find the correct one from maven central looking at dependencies and their versions that are expected.


> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 13:13:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 11 Jan 2019 13:13:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.54103.1547230380128@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681105#comment-13681105 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

I didn't add anything that wasn't indicated by maven, like when it lists the  "declared and unused dependencies" and the "undeclared and used dependencies".    I follow what it was telling me. 

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 15:02:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 11 Jan 2019 15:02:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.54387.1547236920522@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5561 started by Steven Hawkins.
---------------------------------------------
> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 11 17:54:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 11 Jan 2019 17:54:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5596) Remove the Infinispan
 dependency from Teiid Embedded
In-Reply-To: <JIRA.12787195.1547247226000@Atlassian.JIRA>
References: <JIRA.12787195.1547247226000@Atlassian.JIRA>
	<JIRA.12787195.1547247226539@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787195.1547247226000.55266.1547247240053@Atlassian.JIRA>

Ramesh Reddy created TEIID-5596:
-----------------------------------

             Summary: Remove the Infinispan dependency from Teiid Embedded
                 Key: TEIID-5596
                 URL: https://issues.jboss.org/browse/TEIID-5596
             Project: Teiid
          Issue Type: Task
          Components: Embedded, Infinispan, Server
            Reporter: Ramesh Reddy
            Assignee: Ramesh Reddy
             Fix For: 12.0


Infinispan brings a direct dependency on Teiid Embedded in runtime module. Teiid runtime already defines the abstract classes to keep the implementation of the Cache implementation dependent, however TeiiedEmbedded server configuration ignores and brings tight coupling.

Move the Infinispan Cache wrapper implementation to separate project, such that embedded is freed from dependency. 

in Spring Boot I see that the version is defined by Spring's bom and not find a way to a way override that, plus given the version differences the loading of cache fails.  This change should lead to plugging in an independent cache implementation like Redis or Caffeine with Teiid Embedded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 05:44:03 2019
From: issues at jboss.org (Salvatore R (Jira))
Date: Mon, 14 Jan 2019 05:44:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5220) Add support for
 information_schema namespace
In-Reply-To: <JIRA.12729550.1516205965000@Atlassian.JIRA>
References: <JIRA.12729550.1516205965000@Atlassian.JIRA>
	<JIRA.12729550.1516205965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729550.1516205965000.59046.1547462643671@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681452#comment-13681452 ] 

Salvatore R commented on TEIID-5220:
------------------------------------

Hi [~shawkins], I was looking at this issue and I wondered why you decided to implement these tables/views under pg_catalog instead of a separate "information_schema" model/schema. This way the implementation would have been closer to the ANSI-standard and also the potential issue with redirecting queries to an information_schema model added by the user would have been avoided.

> Add support for information_schema namespace
> --------------------------------------------
>
>                 Key: TEIID-5220
>                 URL: https://issues.jboss.org/browse/TEIID-5220
>             Project: Teiid
>          Issue Type: Bug
>          Components: ODBC, Query Engine
>            Reporter: Divyesh Vallabh
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 10.3, 10.2.1
>
>
> The npgsql provider uses the the infomation_schema namespace to query meta information for tables and views.
> Add support for information_schema.tables (
> https://www.postgresql.org/docs/10/static/infoschema-tables.html) to teiid
> Add support for information_schema.views (
> https://www.postgresql.org/docs/10/static/infoschema-views.html) to teiid
> Add support for information_schema.columns (
> https://www.postgresql.org/docs/10/static/infoschema-columns.html) to teiid



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 09:46:05 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 09:46:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5220) Add support for
 information_schema namespace
In-Reply-To: <JIRA.12729550.1516205965000@Atlassian.JIRA>
References: <JIRA.12729550.1516205965000@Atlassian.JIRA>
	<JIRA.12729550.1516205965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729550.1516205965000.63667.1547477165966@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681729#comment-13681729 ] 

Steven Hawkins commented on TEIID-5220:
---------------------------------------

> I was looking at this issue and I wondered why you decided to implement these tables/views under pg_catalog instead of a separate "information_schema" model/schema. 

[~fox123] see the first comment the metadata is specific to our pg protocol.

> This way the implementation would have been closer to the ANSI-standard and also the potential issue with redirecting queries to an information_schema model added by the user would have been avoided.

Yes, we may eventually reserve the information_schema schema name for our use.





> Add support for information_schema namespace
> --------------------------------------------
>
>                 Key: TEIID-5220
>                 URL: https://issues.jboss.org/browse/TEIID-5220
>             Project: Teiid
>          Issue Type: Bug
>          Components: ODBC, Query Engine
>            Reporter: Divyesh Vallabh
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 10.3, 10.2.1
>
>
> The npgsql provider uses the the infomation_schema namespace to query meta information for tables and views.
> Add support for information_schema.tables (
> https://www.postgresql.org/docs/10/static/infoschema-tables.html) to teiid
> Add support for information_schema.views (
> https://www.postgresql.org/docs/10/static/infoschema-views.html) to teiid
> Add support for information_schema.columns (
> https://www.postgresql.org/docs/10/static/infoschema-columns.html) to teiid



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 09:48:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 09:48:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.63696.1547477280720@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5592:
----------------------------------
    Summary: Update or deprecate teiid-quickstarts  (was: Updated or deprecate teiid-quickstarts)


> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 09:48:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 09:48:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.63701.1547477282523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5592:
----------------------------------
    Fix Version/s: 12.1
                       (was: 12.0)


> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 11:12:03 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 11:12:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5596) Remove the Infinispan
 dependency from Teiid Embedded
In-Reply-To: <JIRA.12787195.1547247227000@Atlassian.JIRA>
References: <JIRA.12787195.1547247227000@Atlassian.JIRA>
	<JIRA.12787195.1547247227000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787195.1547247227000.65019.1547482323262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy reassigned TEIID-5596:
-----------------------------------

    Assignee: Steven Hawkins  (was: Ramesh Reddy)


> Remove the Infinispan dependency from Teiid Embedded
> ----------------------------------------------------
>
>                 Key: TEIID-5596
>                 URL: https://issues.jboss.org/browse/TEIID-5596
>             Project: Teiid
>          Issue Type: Task
>          Components: Embedded, Infinispan, Server
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Infinispan brings a direct dependency on Teiid Embedded in runtime module. Teiid runtime already defines the abstract classes to keep the implementation of the Cache implementation dependent, however TeiiedEmbedded server configuration ignores and brings tight coupling.
> Move the Infinispan Cache wrapper implementation to separate project, such that embedded is freed from dependency. 
> in Spring Boot I see that the version is defined by Spring's bom and not find a way to a way override that, plus given the version differences the loading of cache fails.  This change should lead to plugging in an independent cache implementation like Redis or Caffeine with Teiid Embedded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 11:32:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 11:32:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5596) Remove the Infinispan
 dependency from Teiid Embedded
In-Reply-To: <JIRA.12787195.1547247227000@Atlassian.JIRA>
References: <JIRA.12787195.1547247227000@Atlassian.JIRA>
	<JIRA.12787195.1547247227000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787195.1547247227000.65324.1547483524536@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5596.
-----------------------------------
    Resolution: Done


The change makes infinispan optional, but it will be used if it exists in the embedded classpath.  That has been noted in the docs/release notes.  The infinispan specific config methods have been deprecated as we will likely remove that direct integration later.

> Remove the Infinispan dependency from Teiid Embedded
> ----------------------------------------------------
>
>                 Key: TEIID-5596
>                 URL: https://issues.jboss.org/browse/TEIID-5596
>             Project: Teiid
>          Issue Type: Task
>          Components: Embedded, Infinispan, Server
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Infinispan brings a direct dependency on Teiid Embedded in runtime module. Teiid runtime already defines the abstract classes to keep the implementation of the Cache implementation dependent, however TeiiedEmbedded server configuration ignores and brings tight coupling.
> Move the Infinispan Cache wrapper implementation to separate project, such that embedded is freed from dependency. 
> in Spring Boot I see that the version is defined by Spring's bom and not find a way to a way override that, plus given the version differences the loading of cache fails.  This change should lead to plugging in an independent cache implementation like Redis or Caffeine with Teiid Embedded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 12:18:16 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 12:18:16 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5597) Retire teiid.jboss.org
In-Reply-To: <JIRA.12787364.1547486183000@Atlassian.JIRA>
References: <JIRA.12787364.1547486183000@Atlassian.JIRA>
	<JIRA.12787364.1547486183365@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787364.1547486183000.65824.1547486296500@Atlassian.JIRA>

Steven Hawkins created TEIID-5597:
-------------------------------------

             Summary: Retire teiid.jboss.org
                 Key: TEIID-5597
                 URL: https://issues.jboss.org/browse/TEIID-5597
             Project: Teiid
          Issue Type: Task
          Components: Documentation
            Reporter: Steven Hawkins
             Fix For: 12.1


The legacy site will have been unmaintained since approximately a 4/2018.  We can leave archive information, such as doc and old download links in place - but all other content should be removed or ported to teiid.io.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 12:22:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 12:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5598) Updated teiid.io to
	emphasize the runtime
In-Reply-To: <JIRA.12787365.1547486489000@Atlassian.JIRA>
References: <JIRA.12787365.1547486489000@Atlassian.JIRA>
	<JIRA.12787365.1547486489146@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787365.1547486489000.65849.1547486520378@Atlassian.JIRA>

Steven Hawkins created TEIID-5598:
-------------------------------------

             Summary: Updated teiid.io to emphasize the runtime
                 Key: TEIID-5598
                 URL: https://issues.jboss.org/browse/TEIID-5598
             Project: Teiid
          Issue Type: Task
          Components: Documentation
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins


Related to TEIID-5597, we should update teiid.io to better emphasize the runtime and the burgeoning tool chain / limited (wildfly free) docs.

Ideally starting from the landing page we should:
- make it clear our relationship to syndesis
- highlight the cloud tooling option
- introduce the the runtime via openshift quickstarts
- some other link for everyone else (wildfly / developers)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 12:22:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 12:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5598) Updated teiid.io to
	emphasize the runtime
In-Reply-To: <JIRA.12787365.1547486489000@Atlassian.JIRA>
References: <JIRA.12787365.1547486489000@Atlassian.JIRA>
	<JIRA.12787365.1547486489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787365.1547486489000.65850.1547486520625@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-5598:
-------------------------------------

    Assignee:     (was: Steven Hawkins)


> Updated teiid.io to emphasize the runtime
> -----------------------------------------
>
>                 Key: TEIID-5598
>                 URL: https://issues.jboss.org/browse/TEIID-5598
>             Project: Teiid
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Steven Hawkins
>            Priority: Major
>
> Related to TEIID-5597, we should update teiid.io to better emphasize the runtime and the burgeoning tool chain / limited (wildfly free) docs.
> Ideally starting from the landing page we should:
> - make it clear our relationship to syndesis
> - highlight the cloud tooling option
> - introduce the the runtime via openshift quickstarts
> - some other link for everyone else (wildfly / developers)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 12:26:01 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 14 Jan 2019 12:26:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486703000@Atlassian.JIRA>
References: <JIRA.12787366.1547486703000@Atlassian.JIRA>
	<JIRA.12787366.1547486703885@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486703000.65865.1547486761017@Atlassian.JIRA>

Christoph John created TEIID-5599:
-------------------------------------

             Summary: When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
                 Key: TEIID-5599
                 URL: https://issues.jboss.org/browse/TEIID-5599
             Project: Teiid
          Issue Type: Bug
            Reporter: Christoph John
            Assignee: Steven Hawkins


The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.

POST Account HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de-DE
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true

{"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
--batch_id-1547485733072-21
Content-Type:application/http
Content-Transfer-Encoding:binary

The response:

HTTP/1.1 201 Created
Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
Content-Length: 147

{"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
--batch_e834eb7c-df0d-4e22-a423-78cd3638955f
Content-Type: application/http
Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:28:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 13:28:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5066) Move resource-adapters
 configuration style more adaptable to Spring/OpenShift based datasources
In-Reply-To: <JIRA.12711948.1505480304000@Atlassian.JIRA>
References: <JIRA.12711948.1505480304000@Atlassian.JIRA>
	<JIRA.12711948.1505480304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12711948.1505480304000.66287.1547490480241@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy resolved TEIID-5066.
---------------------------------
    Resolution: Out of Date


> Move resource-adapters configuration style more adaptable to Spring/OpenShift based datasources
> -----------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5066
>                 URL: https://issues.jboss.org/browse/TEIID-5066
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: Connector API
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.x
>
>
> The current configuration in the resource-adapters, i.e. ManagedConnectionFactory and managed connection are so tightly integrated with JCA semantics that use of this connection code else where in environments like Spring Boot or Embedded or OpenShift makes it either cumbersome or impossible.
> All resource-adapter modules need to be refactored such that JCA semantics are add-ons rather than main part of it.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:30:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 13:30:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5560) Make Spring Boot port of
 Teiid library to support VDB deployment
In-Reply-To: <JIRA.12782136.1543863849000@Atlassian.JIRA>
References: <JIRA.12782136.1543863849000@Atlassian.JIRA>
	<JIRA.12782136.1543863849000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782136.1543863849000.66297.1547490600272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy resolved TEIID-5560.
---------------------------------
    Fix Version/s: 12.0
       Resolution: Done


Support will be available in 1.0.2 version

> Make Spring Boot port of Teiid library to support VDB deployment
> ----------------------------------------------------------------
>
>                 Key: TEIID-5560
>                 URL: https://issues.jboss.org/browse/TEIID-5560
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.0
>
>
> Spring Boot majorly focuses on the JPA style programming for data virtualization where it gives developers the ability to define the Entity model whereby the VDB internals required are automatically generated deployed.
> In addition to the above, this library also should provide ways to deploy an existing VDB as Thorntail/WildFly does. There should be a process defined to take VDB and create an immutable process with it. It is expected to be used in the generation of OpenShift images for Teiid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:35:05 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 13:35:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5600) Use Caffine as default
 cache implementation with Teiid Spring Boot applications
In-Reply-To: <JIRA.12787373.1547490780000@Atlassian.JIRA>
References: <JIRA.12787373.1547490780000@Atlassian.JIRA>
	<JIRA.12787373.1547490780570@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787373.1547490780000.66330.1547490905406@Atlassian.JIRA>

Ramesh Reddy created TEIID-5600:
-----------------------------------

             Summary: Use Caffine as default cache implementation with Teiid Spring Boot applications
                 Key: TEIID-5600
                 URL: https://issues.jboss.org/browse/TEIID-5600
             Project: Teiid
          Issue Type: Enhancement
          Components: spring-boot
            Reporter: Ramesh Reddy
            Assignee: Ramesh Reddy


Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffine|https://github.com/ben-manes/caffeine]



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:35:05 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 13:35:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5600) Use Caffine as default
 cache implementation with Teiid Spring Boot applications
In-Reply-To: <JIRA.12787373.1547490781000@Atlassian.JIRA>
References: <JIRA.12787373.1547490781000@Atlassian.JIRA>
	<JIRA.12787373.1547490781000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787373.1547490781000.66331.1547490905587@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5600:
--------------------------------
    Description: Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffeine|https://github.com/ben-manes/caffeine]  (was: Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffine|https://github.com/ben-manes/caffeine])


> Use Caffine as default cache implementation with Teiid Spring Boot applications
> -------------------------------------------------------------------------------
>
>                 Key: TEIID-5600
>                 URL: https://issues.jboss.org/browse/TEIID-5600
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffeine|https://github.com/ben-manes/caffeine]



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:35:07 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 13:35:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5601) OData needs to account for
 source order and org.teiid.defaultNullOrder
In-Reply-To: <JIRA.12787374.1547490824000@Atlassian.JIRA>
References: <JIRA.12787374.1547490824000@Atlassian.JIRA>
	<JIRA.12787374.1547490824352@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787374.1547490824000.66338.1547490907882@Atlassian.JIRA>

Steven Hawkins created TEIID-5601:
-------------------------------------

             Summary: OData needs to account for source order and org.teiid.defaultNullOrder
                 Key: TEIID-5601
                 URL: https://issues.jboss.org/browse/TEIID-5601
             Project: Teiid
          Issue Type: Quality Risk
          Components: OData
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


Teiid's default null handling (low) matches that of the odata spec.  However we don't have strict enforcement that pushdown order bys must match that ordering - only an option to do so if it's supported by the source org.teiid.pushdownDefaultOrderBy.  We also have  org.teiid.defaultNullOrder which can be set to something other than low.  In either of those cases the returned ordering will not match the spec: http://docs.oasis-open.org/odata/odata/v4.01/cs01/part1-protocol/odata-v4.01-cs01-part1-protocol.html#_Toc505771210



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 13:35:08 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 13:35:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5600) Use Caffeine as default
 cache implementation with Teiid Spring Boot applications
In-Reply-To: <JIRA.12787373.1547490781000@Atlassian.JIRA>
References: <JIRA.12787373.1547490781000@Atlassian.JIRA>
	<JIRA.12787373.1547490781000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787373.1547490781000.66339.1547490908145@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5600:
--------------------------------
    Summary: Use Caffeine as default cache implementation with Teiid Spring Boot applications  (was: Use Caffine as default cache implementation with Teiid Spring Boot applications)


> Use Caffeine as default cache implementation with Teiid Spring Boot applications
> --------------------------------------------------------------------------------
>
>                 Key: TEIID-5600
>                 URL: https://issues.jboss.org/browse/TEIID-5600
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffeine|https://github.com/ben-manes/caffeine]



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 14:03:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Mon, 14 Jan 2019 14:03:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.66421.1547492580865@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5521:
----------------------------------

    Assignee: Steven Hawkins  (was: Van Halbert)


> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 14:46:04 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 14 Jan 2019 14:46:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5602) Move Teiid Spring Boot to
 Teiid 12 version
In-Reply-To: <JIRA.12787377.1547495158000@Atlassian.JIRA>
References: <JIRA.12787377.1547495158000@Atlassian.JIRA>
	<JIRA.12787377.1547495158504@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787377.1547495158000.66612.1547495164925@Atlassian.JIRA>

Ramesh Reddy created TEIID-5602:
-----------------------------------

             Summary: Move Teiid Spring Boot to Teiid 12 version
                 Key: TEIID-5602
                 URL: https://issues.jboss.org/browse/TEIID-5602
             Project: Teiid
          Issue Type: Task
            Reporter: Ramesh Reddy
            Assignee: Ramesh Reddy


Move the current version supported by teiid spring boot to Teiid 12



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 15:27:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 14 Jan 2019 15:27:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.67010.1547497622098@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681986#comment-13681986 ] 

Steven Hawkins commented on TEIID-5599:
---------------------------------------

It doesn't see like the idProfile should be needed in the insert/post if it is auto-increment.  What happens when you do not specify it?  Also what does the OData metadata for the entity look like, and what does the Teiid/source metadata look like?

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 15:39:02 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 14 Jan 2019 15:39:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.67149.1547498342485@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681996#comment-13681996 ] 

Christoph John commented on TEIID-5599:
---------------------------------------

Hello Steven,
if I do not provide a value for idProfile I get an error. The communication for it looks as follows:

1. request: 

POST Account HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de-DE
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true

{"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
--batch_id-1547497985610-21
Content-Type:application/http
Content-Transfer-Encoding:binary

2. response:
HTTP/1.1 400 Bad Request
Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
Content-Length: 157

{"error":{"code":"TEIID30089","message":"TEIID30089 Required parameter 'my_nutri_diary.Account.idProfile' has no value was set or is an invalid parameter."}}
--batch_37bbb02c-8f9d-42ea-a56f-bcdef07b8568--

3. The relevant metadata:
<EntityType Name="Account">
<Key>
<PropertyRef Name="idProfile"/>
</Key>
<Property Name="idProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`idProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="uuidUser" Type="Edm.String" Nullable="false" MaxLength="36">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`uuidUser`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="Avatar_fkAvatarToAccount" Type="my_nutri_diary.Avatar" Nullable="false"/>
<NavigationProperty Name="BodyWeight_fkBodyWeightToAccount" Type="Collection(my_nutri_diary.BodyWeight)"/>
<NavigationProperty Name="ConfigOptions_fkConfigOptionsToAccount" Type="my_nutri_diary.ConfigOptions" Nullable="false"/>
<NavigationProperty Name="Profile_fkProfileToAccount" Type="my_nutri_diary.Profile" Nullable="false"/>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Account`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>

I am not sure what you mean with Teiid/source metadata, would the vdb export as xml help you here?

Best regards,
 Christoph

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 14 15:42:03 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Mon, 14 Jan 2019 15:42:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.67153.1547498523756@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681996#comment-13681996 ] 

Christoph John edited comment on TEIID-5599 at 1/14/19 3:41 PM:
----------------------------------------------------------------

Hello Steven,
if I do not provide a value for idProfile I get an error. The communication for it looks as follows:

1. request: 

POST Account HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de-DE
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true

{"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
--batch_id-1547497985610-21
Content-Type:application/http
Content-Transfer-Encoding:binary

2. response:
HTTP/1.1 400 Bad Request
Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
Content-Length: 157

{"error":{"code":"TEIID30089","message":"TEIID30089 Required parameter 'my_nutri_diary.Account.idProfile' has no value was set or is an invalid parameter."}}
--batch_37bbb02c-8f9d-42ea-a56f-bcdef07b8568--

3. The relevant metadata:
<EntityType Name="Account">
<Key>
<PropertyRef Name="idProfile"/>
</Key>
<Property Name="idProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`idProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="uuidUser" Type="Edm.String" Nullable="false" MaxLength="36">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`uuidUser`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="Avatar_fkAvatarToAccount" Type="my_nutri_diary.Avatar" Nullable="false"/>
<NavigationProperty Name="BodyWeight_fkBodyWeightToAccount" Type="Collection(my_nutri_diary.BodyWeight)"/>
<NavigationProperty Name="ConfigOptions_fkConfigOptionsToAccount" Type="my_nutri_diary.ConfigOptions" Nullable="false"/>
<NavigationProperty Name="Profile_fkProfileToAccount" Type="my_nutri_diary.Profile" Nullable="false"/>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Account`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>

I am not sure what you mean with Teiid/source metadata, would the vdb export as xml help you here?

Update: I also should mention, that I cannot set a primary key to anything different than not null in the mysql database. 

Best regards,
 Christoph


was (Author: cjohn001):
Hello Steven,
if I do not provide a value for idProfile I get an error. The communication for it looks as follows:

1. request: 

POST Account HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de-DE
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true

{"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
--batch_id-1547497985610-21
Content-Type:application/http
Content-Transfer-Encoding:binary

2. response:
HTTP/1.1 400 Bad Request
Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
Content-Length: 157

{"error":{"code":"TEIID30089","message":"TEIID30089 Required parameter 'my_nutri_diary.Account.idProfile' has no value was set or is an invalid parameter."}}
--batch_37bbb02c-8f9d-42ea-a56f-bcdef07b8568--

3. The relevant metadata:
<EntityType Name="Account">
<Key>
<PropertyRef Name="idProfile"/>
</Key>
<Property Name="idProfile" Type="Edm.Int64" Nullable="false">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`idProfile`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<Property Name="uuidUser" Type="Edm.String" Nullable="false" MaxLength="36">
<Annotation Term="teiid.NAMEINSOURCE">
<String>`uuidUser`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="teiid.CASE_SENSITIVE">
<Bool>true</Bool>
</Annotation>
</Property>
<NavigationProperty Name="Avatar_fkAvatarToAccount" Type="my_nutri_diary.Avatar" Nullable="false"/>
<NavigationProperty Name="BodyWeight_fkBodyWeightToAccount" Type="Collection(my_nutri_diary.BodyWeight)"/>
<NavigationProperty Name="ConfigOptions_fkConfigOptionsToAccount" Type="my_nutri_diary.ConfigOptions" Nullable="false"/>
<NavigationProperty Name="Profile_fkProfileToAccount" Type="my_nutri_diary.Profile" Nullable="false"/>
<Annotation Term="teiid.NAMEINSOURCE">
<String>`Account`</String>
</Annotation>
<Annotation Term="teiid.UPDATABLE">
<Bool>true</Bool>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:ALLOW_MATVIEW_MANAGEMENT">
<String>false</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_ONERROR_ACTION">
<String>WAIT</String>
</Annotation>
<Annotation Term="my_nutri_diary.teiid_rel:MATVIEW_SHARE_SCOPE">
<String>NONE</String>
</Annotation>
</EntityType>

I am not sure what you mean with Teiid/source metadata, would the vdb export as xml help you here?

Best regards,
 Christoph

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 08:11:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 08:11:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.77768.1547557860874@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682295#comment-13682295 ] 

Steven Hawkins commented on TEIID-5599:
---------------------------------------

> I am not sure what you mean with Teiid/source metadata, would the vdb export as xml help you here?

Yes that would allow me to better reproduce this.

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 08:11:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 08:11:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.77771.1547557861594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5599:
----------------------------------
    Fix Version/s: 12.1


> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 08:23:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 08:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5601) OData needs to account for
 source order and org.teiid.defaultNullOrder
In-Reply-To: <JIRA.12787374.1547490824000@Atlassian.JIRA>
References: <JIRA.12787374.1547490824000@Atlassian.JIRA>
	<JIRA.12787374.1547490824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787374.1547490824000.77818.1547558580122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5601:
----------------------------------
    Fix Version/s: 12.0.1
                   11.2.2


> OData needs to account for source order and org.teiid.defaultNullOrder
> ----------------------------------------------------------------------
>
>                 Key: TEIID-5601
>                 URL: https://issues.jboss.org/browse/TEIID-5601
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> Teiid's default null handling (low) matches that of the odata spec.  However we don't have strict enforcement that pushdown order bys must match that ordering - only an option to do so if it's supported by the source org.teiid.pushdownDefaultOrderBy.  We also have  org.teiid.defaultNullOrder which can be set to something other than low.  In either of those cases the returned ordering will not match the spec: http://docs.oasis-open.org/odata/odata/v4.01/cs01/part1-protocol/odata-v4.01-cs01-part1-protocol.html#_Toc505771210



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 08:31:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Tue, 15 Jan 2019 08:31:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.78026.1547559060770@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682313#comment-13682313 ] 

Christoph John commented on TEIID-5599:
---------------------------------------

Hello Steven,
attached you find the vdb xml description:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<vdb name="svc" version="1">
    <description/>
    <property name="validationDateTime" value="Fri Jan 11 01:38:15 CET 2019"/>
    <property name="validationVersion" value="11.2.0"/>
    <model name="my_nutri_diary">
        <source connection-jndi-name="java:/my_nutri_diary" name="my_nutri_diary" translator-name="mysql"/>
        <metadata type="DDL">
            <![CDATA[

CREATE FOREIGN TABLE Account (
	idProfile long NOT NULL AUTO_INCREMENT OPTIONS(NAMEINSOURCE '`idProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	uuidUser string(36) NOT NULL OPTIONS(NAMEINSOURCE '`uuidUser`', NATIVE_TYPE 'CHAR'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(idProfile),
	CONSTRAINT uuidUser_UNIQUE UNIQUE(uuidUser)
) OPTIONS(NAMEINSOURCE '`Account`', UPDATABLE 'TRUE');

CREATE FOREIGN TABLE Avatar (
	fkProfile long NOT NULL OPTIONS(NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	AvatarImg blob(65535) OPTIONS(NAMEINSOURCE '`AvatarImg`', NATIVE_TYPE 'BLOB'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkAvatarToAccount FOREIGN KEY(fkProfile) REFERENCES Account(idProfile)
) OPTIONS(NAMEINSOURCE '`Avatar`', UPDATABLE 'TRUE');

CREATE FOREIGN TABLE BodyWeight (
	idBodyWeight long NOT NULL AUTO_INCREMENT OPTIONS(NAMEINSOURCE '`idBodyWeight`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	fkProfile long NOT NULL OPTIONS(NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	WeightMeasurementDateTime timestamp NOT NULL OPTIONS(NAMEINSOURCE '`WeightMeasurementDateTime`', NATIVE_TYPE 'DATETIME'),
	Weight float NOT NULL OPTIONS(NAMEINSOURCE '`Weight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(idBodyWeight),
	CONSTRAINT fkBodyWeightToAccount FOREIGN KEY(fkProfile) REFERENCES Account(idProfile)
) OPTIONS(NAMEINSOURCE '`BodyWeight`', UPDATABLE 'TRUE');

CREATE FOREIGN TABLE ConfigOptions (
	fkProfile long NOT NULL OPTIONS(NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	MUnitWeight string(2) DEFAULT 'kg' OPTIONS(NAMEINSOURCE '`MUnitWeight`', NATIVE_TYPE 'ENUM'),
	MUnitLength string(2) DEFAULT 'cm' OPTIONS(NAMEINSOURCE '`MUnitLength`', NATIVE_TYPE 'ENUM'),
	MUnitEnergy string(4) DEFAULT 'kcal' OPTIONS(NAMEINSOURCE '`MUnitEnergy`', NATIVE_TYPE 'ENUM'),
	MUnitLiquids string(2) DEFAULT 'ml' OPTIONS(NAMEINSOURCE '`MUnitLiquids`', NATIVE_TYPE 'ENUM'),
	MUnitTime string(3) DEFAULT '24h' OPTIONS(NAMEINSOURCE '`MUnitTime`', NATIVE_TYPE 'ENUM'),
	EnableDrinkReminder boolean DEFAULT '0' OPTIONS(NAMEINSOURCE '`EnableDrinkReminder`', NATIVE_TYPE 'BIT'),
	PreferredCountryCodeForSearch string(2) DEFAULT 'de' OPTIONS(NAMEINSOURCE '`PreferredCountryCodeForSearch`', NATIVE_TYPE 'VARCHAR'),
	EnableInternationalSearch boolean DEFAULT '1' OPTIONS(NAMEINSOURCE '`EnableInternationalSearch`', NATIVE_TYPE 'BIT'),
	NumberOfActiveMeals long DEFAULT '4' OPTIONS(NAMEINSOURCE '`NumberOfActiveMeals`', NATIVE_TYPE 'INT UNSIGNED'),
	Meal1Name string(45) OPTIONS(NAMEINSOURCE '`Meal1Name`', NATIVE_TYPE 'VARCHAR'),
	Meal1StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal1StartTime`', NATIVE_TYPE 'TIME'),
	Meal2Name string(45) OPTIONS(NAMEINSOURCE '`Meal2Name`', NATIVE_TYPE 'VARCHAR'),
	Meal2StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal2StartTime`', NATIVE_TYPE 'TIME'),
	Meal3Name string(45) OPTIONS(NAMEINSOURCE '`Meal3Name`', NATIVE_TYPE 'VARCHAR'),
	Meal3StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal3StartTime`', NATIVE_TYPE 'TIME'),
	Meal4Name string(45) OPTIONS(NAMEINSOURCE '`Meal4Name`', NATIVE_TYPE 'VARCHAR'),
	Meal4StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal4StartTime`', NATIVE_TYPE 'TIME'),
	Meal5Name string(45) OPTIONS(NAMEINSOURCE '`Meal5Name`', NATIVE_TYPE 'VARCHAR'),
	Meal5StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal5StartTime`', NATIVE_TYPE 'TIME'),
	Meal6Name string(45) OPTIONS(NAMEINSOURCE '`Meal6Name`', NATIVE_TYPE 'VARCHAR'),
	Meal6StartTime time DEFAULT '00:00:00' OPTIONS(NAMEINSOURCE '`Meal6StartTime`', NATIVE_TYPE 'TIME'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkConfigOptionsToAccount FOREIGN KEY(fkProfile) REFERENCES Account(idProfile)
) OPTIONS(NAMEINSOURCE '`ConfigOptions`', UPDATABLE 'TRUE');

CREATE FOREIGN TABLE Profile (
	fkProfile long NOT NULL OPTIONS(NAMEINSOURCE '`fkProfile`', NATIVE_TYPE 'BIGINT UNSIGNED'),
	BodyHeight float DEFAULT '0.000' OPTIONS(NAMEINSOURCE '`BodyHeight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	GoalWeight float DEFAULT '0.000' OPTIONS(NAMEINSOURCE '`GoalWeight`', NATIVE_TYPE 'FLOAT UNSIGNED'),
	Gender string(1) DEFAULT 'm' OPTIONS(NAMEINSOURCE '`Gender`', NATIVE_TYPE 'ENUM'),
	BirthDate date DEFAULT '1980-01-01' OPTIONS(NAMEINSOURCE '`BirthDate`', NATIVE_TYPE 'DATE'),
	ActivityLevel string(17) DEFAULT 'strActive' OPTIONS(NAMEINSOURCE '`ActivityLevel`', NATIVE_TYPE 'ENUM'),
	CONSTRAINT "PRIMARY" PRIMARY KEY(fkProfile),
	CONSTRAINT fkProfileToAccount FOREIGN KEY(fkProfile) REFERENCES Account(idProfile)
) OPTIONS(NAMEINSOURCE '`Profile`', UPDATABLE 'TRUE');

]]>
        </metadata>
    </model>
    <data-role allow-create-temporary-tables="false" any-authenticated="true" grant-all="false" name="odata">
        <description/>
        <permission>
            <resource-name>my_nutri_diary.ConfigOptions</resource-name>
            <allow-delete>false</allow-delete>
            <condition>ConfigOptions.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))</condition>
        </permission>
        <permission>
            <resource-name>my_nutri_diary.Account</resource-name>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
            <condition>Account.uuidUser = LEFT(user(), 36)</condition>
        </permission>
        <permission>
            <resource-name>my_nutri_diary.Profile</resource-name>
            <allow-delete>false</allow-delete>
            <condition>Profile.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))</condition>
        </permission>
        <permission>
            <resource-name>my_nutri_diary</resource-name>
            <allow-create>true</allow-create>
            <allow-read>true</allow-read>
            <allow-update>true</allow-update>
            <allow-delete>true</allow-delete>
            <allow-execute>false</allow-execute>
            <allow-alter>false</allow-alter>
        </permission>
        <permission>
            <resource-name>my_nutri_diary.BodyWeight</resource-name>
            <condition>BodyWeight.fkProfile in  (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )</condition>
        </permission>
        <permission>
            <resource-name>sysadmin</resource-name>
            <allow-create>false</allow-create>
            <allow-read>false</allow-read>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
            <allow-execute>false</allow-execute>
            <allow-alter>false</allow-alter>
        </permission>
    </data-role>
</vdb>


> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 09:22:01 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 15 Jan 2019 09:22:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5532) Common table projection
 minimization does not account for usage in a subquery nested in an
 aggregate or in some view scenarios
In-Reply-To: <JIRA.12778365.1541623488000@Atlassian.JIRA>
References: <JIRA.12778365.1541623488000@Atlassian.JIRA>
	<JIRA.12778365.1541623488000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12778365.1541623488000.80071.1547562121384@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5532:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> Common table projection minimization does not account for usage in a subquery nested in an aggregate or in some view scenarios
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5532
>                 URL: https://issues.jboss.org/browse/TEIID-5532
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Blocker
>             Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1, 8.12.17.6_4
>
>
> Nesting the usage of a common table in an aggregate means that the columns can be removed inappropriately by projection minimization.  A query such as:
> with CTE1 as /*+ no_inline */ (SELECT e1, e2, e3 from pm1.g1) 
> select array_agg((select e3 from cte1 where e1=pm1.g2.e1 and e2=pm1.g2.e2)) from pm1.g2
> will return null values for all e3 as projection minimization of CTE1 will replace the column with a null value.
> A similar situation occurs when the query above is defined instead in a view.  A similar issue was captured on TEIID-5535



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:02:08 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 10:02:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5603) Support of JAVA 11 has
 failures running arquillian tests
In-Reply-To: <JIRA.12787533.1547564374000@Atlassian.JIRA>
References: <JIRA.12787533.1547564374000@Atlassian.JIRA>
	<JIRA.12787533.1547564374644@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787533.1547564374000.80623.1547564528045@Atlassian.JIRA>

Van Halbert created TEIID-5603:
----------------------------------

             Summary: Support of JAVA 11 has failures running arquillian tests
                 Key: TEIID-5603
                 URL: https://issues.jboss.org/browse/TEIID-5603
             Project: Teiid
          Issue Type: Bug
          Components: Build/Kits
    Affects Versions: 12.x
            Reporter: Van Halbert
            Assignee: Steven Hawkins


The normal "release install" build works, unfortunately the arquillian tests fail with following test failures:

{code}
[ERROR] Errors: 
[ERROR]   IntegrationTestOData4.testCORS:235 ? NoClassDefFound javax/xml/bind/JAXBExcept...
[ERROR]   IntegrationTestOData4.testCompositeKeyTimestamp:179 ? NoClassDefFound javax/xm...
[ERROR]   IntegrationTestOData4.testGetDataInGzip:294 ? NoClassDefFound javax/xml/bind/J...
[ERROR]   IntegrationTestOData4.testOdata:87 ? NoClassDefFound javax/xml/bind/JAXBExcept...
[ERROR]   IntegrationTestOData4.testOdataMetadataError:210 ? NoClassDefFound javax/xml/b...
[ERROR]   IntegrationTestOData4.testPutDataInGzip:344 ? NoClassDefFound javax/xml/bind/J...
[ERROR]   IntegrationTestOData4.testStaticServlet:256 ? NoClassDefFound javax/xml/bind/J...
{code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


From issues at jboss.org  Tue Jan 15 10:05:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 10:05:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.80641.1547564701806@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682393#comment-13682393 ] 

Van Halbert commented on TEIID-5593:
------------------------------------

See [TEIID-5603] for the dependent issue.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:06:10 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 10:06:10 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.80686.1547564770859@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682393#comment-13682393 ] 

Van Halbert edited comment on TEIID-5593 at 1/15/19 10:05 AM:
--------------------------------------------------------------

See [TEIID-5603] for the dependent issue, as the travis build will fail due to arquillian test failure.


was (Author: van.halbert):
See [TEIID-5603] for the dependent issue.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:11:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 10:11:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5603) Support of JAVA 11 has
 failures running arquillian tests
In-Reply-To: <JIRA.12787533.1547564375000@Atlassian.JIRA>
References: <JIRA.12787533.1547564375000@Atlassian.JIRA>
	<JIRA.12787533.1547564375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787533.1547564375000.80728.1547565060756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5603.
-----------------------------------
    Resolution: Rejected


Until a later wildfly version java 11 is not supported.

> Support of JAVA 11 has failures running arquillian tests
> --------------------------------------------------------
>
>                 Key: TEIID-5603
>                 URL: https://issues.jboss.org/browse/TEIID-5603
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> The normal "release install" build works, unfortunately the arquillian tests fail with following test failures:
> {code}
> [ERROR] Errors: 
> [ERROR]   IntegrationTestOData4.testCORS:235 ? NoClassDefFound javax/xml/bind/JAXBExcept...
> [ERROR]   IntegrationTestOData4.testCompositeKeyTimestamp:179 ? NoClassDefFound javax/xm...
> [ERROR]   IntegrationTestOData4.testGetDataInGzip:294 ? NoClassDefFound javax/xml/bind/J...
> [ERROR]   IntegrationTestOData4.testOdata:87 ? NoClassDefFound javax/xml/bind/JAXBExcept...
> [ERROR]   IntegrationTestOData4.testOdataMetadataError:210 ? NoClassDefFound javax/xml/b...
> [ERROR]   IntegrationTestOData4.testPutDataInGzip:344 ? NoClassDefFound javax/xml/bind/J...
> [ERROR]   IntegrationTestOData4.testStaticServlet:256 ? NoClassDefFound javax/xml/bind/J...
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


From issues at jboss.org  Tue Jan 15 10:18:02 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 10:18:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.80874.1547565482643@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682402#comment-13682402 ] 

Van Halbert commented on TEIID-5593:
------------------------------------

Since you're saying the tests won't work until a later version of Wildfly, so I assume this jira should be delayed until such time.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 10:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.80920.1547565660967@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682405#comment-13682405 ] 

Steven Hawkins commented on TEIID-5593:
---------------------------------------

No, that's just the arquillian tests everything else should run.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:23:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 10:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.80927.1547565780528@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682408#comment-13682408 ] 

Van Halbert commented on TEIID-5593:
------------------------------------

Ok, just wanted to make sure you are ok with travis build failure, as its currently configured.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 10:54:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 10:54:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.81551.1547567641430@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682428#comment-13682428 ] 

Steven Hawkins commented on TEIID-5593:
---------------------------------------

No, just don't run arquillian with java 11.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 11:32:13 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 15 Jan 2019 11:32:13 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5550) DISTINCT pushed down
 incorrectly in some cases
In-Reply-To: <JIRA.12780473.1542819291000@Atlassian.JIRA>
References: <JIRA.12780473.1542819291000@Atlassian.JIRA>
	<JIRA.12780473.1542819291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12780473.1542819291000.82136.1547569933078@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5550:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> DISTINCT pushed down incorrectly in some cases
> ----------------------------------------------
>
>                 Key: TEIID-5550
>                 URL: https://issues.jboss.org/browse/TEIID-5550
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 8.12.15.6_4
>         Environment: JDV 6.4.5
>            Reporter: Marc Shirley
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 11.1.2, 12.0, 11.2.1, 8.12.17.6_4
>
>
> The parent DISTINCT is being removed over joins in particular situations.  This is a regression from TEIID-3063 TEIID-3062.
> Conditions:
> - basic query structure is select distinct col from a join b on a.col2 = b.col2
> - a sort merge join variant must have been planned
> - the sort must not be pushed to one of the children
> - the projection related conditions of TEIID-3062 / TEIID-3063 must be met
> - there is a one to many relationship
> The result is that the parent distinct will be inappropriately removed, such that the output of the join can contain repetition of the col value when it should be distinct.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 11:59:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 11:59:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5425) Concurrency/timing issues
 observed with travis builds
In-Reply-To: <JIRA.12760839.1532009490000@Atlassian.JIRA>
References: <JIRA.12760839.1532009490000@Atlassian.JIRA>
	<JIRA.12760839.1532009490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12760839.1532009490000.82394.1547571540339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5425:
----------------------------------
    Fix Version/s: 12.1
                       (was: 12.x)


> Concurrency/timing issues observed with travis builds
> -----------------------------------------------------
>
>                 Key: TEIID-5425
>                 URL: https://issues.jboss.org/browse/TEIID-5425
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Several unit tests have been observed to fail during travis builds occasionally:
> 1. TestODBCSocketTransport.testRegClass:757 ?? PSQL ResultSet not positioned prope...
> 2. TestExternalMatViews.testLazyUpdate:930 expected:<2> but was:<1> (see https://api.travis-ci.org/v3/job/405801976/log.txt)
> 3. [ERROR]   TestLocalConnections.testWaitForLoadTimeout:475
> 4. From  https://api.travis-ci.org/v3/job/415138409/log.txt
> [ERROR] testReplication(org.teiid.systemmodel.TestReplication)  Time elapsed: 35.21 s  <<< FAILURE!
> java.lang.AssertionError: expected:<0.9164140964242746> but was:<0.18750528722359294>
> 	at org.teiid.systemmodel.TestReplication.testReplication(TestReplication.java:122)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


From issues at jboss.org  Tue Jan 15 12:00:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:00:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5425) Concurrency/timing issues
 observed with travis builds
In-Reply-To: <JIRA.12760839.1532009490000@Atlassian.JIRA>
References: <JIRA.12760839.1532009490000@Atlassian.JIRA>
	<JIRA.12760839.1532009490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12760839.1532009490000.82397.1547571603025@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682482#comment-13682482 ] 

Steven Hawkins commented on TEIID-5425:
---------------------------------------

Added to 12.1 to address 1/2 - the materialization tests routinely fail.

> Concurrency/timing issues observed with travis builds
> -----------------------------------------------------
>
>                 Key: TEIID-5425
>                 URL: https://issues.jboss.org/browse/TEIID-5425
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Several unit tests have been observed to fail during travis builds occasionally:
> 1. TestODBCSocketTransport.testRegClass:757 ?? PSQL ResultSet not positioned prope...
> 2. TestExternalMatViews.testLazyUpdate:930 expected:<2> but was:<1> (see https://api.travis-ci.org/v3/job/405801976/log.txt)
> 3. [ERROR]   TestLocalConnections.testWaitForLoadTimeout:475
> 4. From  https://api.travis-ci.org/v3/job/415138409/log.txt
> [ERROR] testReplication(org.teiid.systemmodel.TestReplication)  Time elapsed: 35.21 s  <<< FAILURE!
> java.lang.AssertionError: expected:<0.9164140964242746> but was:<0.18750528722359294>
> 	at org.teiid.systemmodel.TestReplication.testReplication(TestReplication.java:122)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


From issues at jboss.org  Tue Jan 15 12:01:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:01:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5598) Updated teiid.io to
	emphasize the runtime
In-Reply-To: <JIRA.12787365.1547486489000@Atlassian.JIRA>
References: <JIRA.12787365.1547486489000@Atlassian.JIRA>
	<JIRA.12787365.1547486489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787365.1547486489000.82405.1547571661554@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5598:
----------------------------------
    Fix Version/s: 12.1


> Updated teiid.io to emphasize the runtime
> -----------------------------------------
>
>                 Key: TEIID-5598
>                 URL: https://issues.jboss.org/browse/TEIID-5598
>             Project: Teiid
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Related to TEIID-5597, we should update teiid.io to better emphasize the runtime and the burgeoning tool chain / limited (wildfly free) docs.
> Ideally starting from the landing page we should:
> - make it clear our relationship to syndesis
> - highlight the cloud tooling option
> - introduce the the runtime via openshift quickstarts
> - some other link for everyone else (wildfly / developers)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:07:07 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:07:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5583) Provide ability to monitor
 how much memory matviews are using
In-Reply-To: <JIRA.12785931.1546514707000@Atlassian.JIRA>
References: <JIRA.12785931.1546514707000@Atlassian.JIRA>
	<JIRA.12785931.1546514707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785931.1546514707000.82434.1547572027326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5583.
-----------------------------------
    Resolution: Won't Fix


Marking as won't fix for now - until there's a determination of what's needed.  The residual heap memory footprint of a materialized view will be proportional to the number of rows / working page size - but is generally small enough as to not be a primary consideration when determining the overall heap.  The actual page data will swap to disk as needed.  The rule of thumb from the docs is conservative as to allow for plenty of working heap space, retaining soft references to index pages, etc.

> Provide ability to monitor how much memory matviews are using
> -------------------------------------------------------------
>
>                 Key: TEIID-5583
>                 URL: https://issues.jboss.org/browse/TEIID-5583
>             Project: Teiid
>          Issue Type: Enhancement
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>
> In the docs it says "Internal materialization (and temp tables in general) have memory overhead for each page. A rough guideline is that there can be 100 million rows in all materialized tables across all VDBs for every gigabyte of heap."
> But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:09:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:09:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5491) Provide Benchmarking based
	upon TPC-H
In-Reply-To: <JIRA.12772739.1538576515000@Atlassian.JIRA>
References: <JIRA.12772739.1538576515000@Atlassian.JIRA>
	<JIRA.12772739.1538576515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12772739.1538576515000.82451.1547572141025@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-5491:
-------------------------------------

    Fix Version/s: Open To Community
         Assignee:     (was: Steven Hawkins)


> Provide Benchmarking based upon TPC-H
> -------------------------------------
>
>                 Key: TEIID-5491
>                 URL: https://issues.jboss.org/browse/TEIID-5491
>             Project: Teiid
>          Issue Type: Task
>            Reporter: Steven Hawkins
>            Priority: Major
>             Fix For: Open To Community
>
>
> We should obtain and provide results around TCP-H 
> from http://www.tpc.org/tpc_documents_current_versions/current_specifications.asp



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:09:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:09:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5523) Allow for xsd schema
 association with vdb.xml
In-Reply-To: <JIRA.12776813.1540833741000@Atlassian.JIRA>
References: <JIRA.12776813.1540833741000@Atlassian.JIRA>
	<JIRA.12776813.1540833741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776813.1540833741000.82462.1547572144368@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5523:
----------------------------------
    Fix Version/s: 12.1


> Allow for xsd schema association with vdb.xml
> ---------------------------------------------
>
>                 Key: TEIID-5523
>                 URL: https://issues.jboss.org/browse/TEIID-5523
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Using Teiid Thorntail an exception is thrown at deployment when I attempt to associate an xsd with the vdb.xml file.  This would be helpful to assist with vdb editing.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:09:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:09:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.82465.1547572144974@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-5590:
-------------------------------------

    Assignee: Ramesh Reddy  (was: Barry LaFond)


> vdb-maven-plugin - version 1.3 breaks build lifecycle
> -----------------------------------------------------
>
>                 Key: TEIID-5590
>                 URL: https://issues.jboss.org/browse/TEIID-5590
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits, VDB
>         Environment: {code}
> 2019-01-08 15:49:30
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
> Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
> 2019-01-08 15:52:36
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
> Maven home: /opt/maven
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
> 2019-01-08 15:52:40
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
> openjdk version "1.8.0_192"
> OpenJDK Runtime Environment (build 1.8.0_192-b26)
> OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
> {code}
>            Reporter: G. Richard Bellamy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.x
>
>
> When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
> {code}
> [INFO] 'package' is a phase corresponding to this plugin:
> org.teiid:vdb-maven-plugin:vdb
> It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
> * validate: Not defined
> * initialize: Not defined
> * generate-sources: Not defined
> * process-sources: Not defined
> * generate-resources: Not defined
> * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
> * compile: org.apache.maven.plugins:maven-compiler-plugin:compile
> * process-classes: Not defined
> * generate-test-sources: Not defined
> * process-test-sources: Not defined
> * generate-test-resources: Not defined
> * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
> * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
> * process-test-classes: Not defined
> * test: org.apache.maven.plugins:maven-surefire-plugin:test
> * prepare-package: Not defined
> * package: org.teiid:vdb-maven-plugin:vdb
> * pre-integration-test: Not defined
> * integration-test: Not defined
> * post-integration-test: Not defined
> * verify: Not defined
> * install: org.apache.maven.plugins:maven-install-plugin:install
> * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:09:06 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:09:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.82469.1547572146079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5590:
----------------------------------
    Fix Version/s: 12.x


> vdb-maven-plugin - version 1.3 breaks build lifecycle
> -----------------------------------------------------
>
>                 Key: TEIID-5590
>                 URL: https://issues.jboss.org/browse/TEIID-5590
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits, VDB
>         Environment: {code}
> 2019-01-08 15:49:30
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
> Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
> 2019-01-08 15:52:36
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
> Maven home: /opt/maven
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
> 2019-01-08 15:52:40
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
> openjdk version "1.8.0_192"
> OpenJDK Runtime Environment (build 1.8.0_192-b26)
> OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
> {code}
>            Reporter: G. Richard Bellamy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.x
>
>
> When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
> {code}
> [INFO] 'package' is a phase corresponding to this plugin:
> org.teiid:vdb-maven-plugin:vdb
> It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
> * validate: Not defined
> * initialize: Not defined
> * generate-sources: Not defined
> * process-sources: Not defined
> * generate-resources: Not defined
> * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
> * compile: org.apache.maven.plugins:maven-compiler-plugin:compile
> * process-classes: Not defined
> * generate-test-sources: Not defined
> * process-test-sources: Not defined
> * generate-test-resources: Not defined
> * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
> * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
> * process-test-classes: Not defined
> * test: org.apache.maven.plugins:maven-surefire-plugin:test
> * prepare-package: Not defined
> * package: org.teiid:vdb-maven-plugin:vdb
> * pre-integration-test: Not defined
> * integration-test: Not defined
> * post-integration-test: Not defined
> * verify: Not defined
> * install: org.apache.maven.plugins:maven-install-plugin:install
> * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:10:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:10:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5523) Allow for xsd schema
 association with vdb.xml
In-Reply-To: <JIRA.12776813.1540833741000@Atlassian.JIRA>
References: <JIRA.12776813.1540833741000@Atlassian.JIRA>
	<JIRA.12776813.1540833741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776813.1540833741000.82475.1547572201211@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682489#comment-13682489 ] 

Steven Hawkins commented on TEIID-5523:
---------------------------------------

I'll validate that this works as expected for at least embedded.

> Allow for xsd schema association with vdb.xml
> ---------------------------------------------
>
>                 Key: TEIID-5523
>                 URL: https://issues.jboss.org/browse/TEIID-5523
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Using Teiid Thorntail an exception is thrown at deployment when I attempt to associate an xsd with the vdb.xml file.  This would be helpful to assist with vdb editing.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:10:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:10:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5503) Create or change ODBC
 driver to be compatible with Microsoft Power BI
In-Reply-To: <JIRA.12773685.1539171780000@Atlassian.JIRA>
References: <JIRA.12773685.1539171780000@Atlassian.JIRA>
	<JIRA.12773685.1539171780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773685.1539171780000.82485.1547572204020@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5503:
----------------------------------
    Fix Version/s: Open To Community


> Create or change ODBC driver to be compatible with Microsoft Power BI
> ---------------------------------------------------------------------
>
>                 Key: TEIID-5503
>                 URL: https://issues.jboss.org/browse/TEIID-5503
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: ODBC
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: Open To Community
>
>         Attachments: qs-connect-data_02.png, qs-connect-data_03.png
>
>
> Customer request to customise the ODBC driver, adding extra feature as reported here: https://docs.microsoft.com/en-us/power-query/odbc



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:13:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:13:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5512) No transaction associated
 with the current thread
In-Reply-To: <JIRA.12775656.1540202036000@Atlassian.JIRA>
References: <JIRA.12775656.1540202036000@Atlassian.JIRA>
	<JIRA.12775656.1540202036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12775656.1540202036000.82516.1547572380464@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5512.
-----------------------------------
    Resolution: Cannot Reproduce


Marking as non-reproducible for now.  If you can get this to occur with Teiid 11, please reopen and if possible provide a trace log of org.teiid.TXN_LOG

> No transaction associated with the current thread
> -------------------------------------------------
>
>                 Key: TEIID-5512
>                 URL: https://issues.jboss.org/browse/TEIID-5512
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 10.3.4
>            Reporter: Bram Gadeyne
>            Assignee: Steven Hawkins
>            Priority: Major
>
> I'm facing this problem but I'm not sure where or when it occurs. It seems to be randomly. The virtual procedure that is run while this problem occurs, copies data from one xa-datasource to a temp table and then inserts it into a non-xa datasource.
> 2018-10-22 09:50:28,361 WARN  [org.teiid.PROCESSOR] (Worker25_QueryProcessorQueue73179) F274YMAVci29 TEIID31200 Lower level transaction Local transaction (delegate=TransactionImple < ac, BasicAction: 0:ffffac130002:-2cc3b1fb:5bcd8cc9:f717 status: ActionStatus.RUNNING >, owner=Local transaction context for provider JBoss JTA transaction provider) not properly ended, rolling back.
> 2018-10-22 09:50:28,361 WARN  [org.teiid.PROCESSOR] (Worker25_QueryProcessorQueue73179) F274YMAVci29 TEIID30028 Failed to properly rollback autowrap transaction properly: org.teiid.client.xa.XATransactionException: TEIID30535 java.lang.IllegalStateException: No transaction associated with the current thread
> 	at org.teiid.dqp.internal.process.TransactionServerImpl.rollbackDirect(TransactionServerImpl.java:432)
> 	at org.teiid.dqp.internal.process.TransactionServerImpl.rollback(TransactionServerImpl.java:551)
> 	at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.teiid.logging.LogManager$LoggingProxy.invoke(LogManager.java:117)
> 	at com.sun.proxy.$Proxy25.rollback(Unknown Source)
> 	at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:574)
> 	at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:375)
> 	at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
> 	at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
> 	at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
> 	at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
> 	at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: No transaction associated with the current thread
> 	at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:81)
> 	at org.teiid.dqp.internal.process.TransactionServerImpl.rollbackDirect(TransactionServerImpl.java:426)
> 	... 16 more
> 2018-10-22 09:50:28,389 WARN  [org.teiid.PROCESSOR] (Worker22_QueryProcessorQueue73181) F274YMAVci29 TEIID30020 Processing exception for request F274YMAVci29.39 'TEIID30538 java.lang.IllegalStateException: WFTXN0007: A transaction is already associated with the current thread'. Originally XATransactionException ContextTransactionManager.java:140. Enable more detailed logging to see the entire stacktrace.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:22:14 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 12:22:14 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5600) Use Caffeine as default
 cache implementation with Teiid Spring Boot applications
In-Reply-To: <JIRA.12787373.1547490781000@Atlassian.JIRA>
References: <JIRA.12787373.1547490781000@Atlassian.JIRA>
	<JIRA.12787373.1547490781000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787373.1547490781000.82572.1547572934517@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682499#comment-13682499 ] 

Steven Hawkins commented on TEIID-5600:
---------------------------------------

 I'll also look to then replace the two-queue caches used by the buffer manager and memory buffer tier at which point we will just pull this into the core.

> Use Caffeine as default cache implementation with Teiid Spring Boot applications
> --------------------------------------------------------------------------------
>
>                 Key: TEIID-5600
>                 URL: https://issues.jboss.org/browse/TEIID-5600
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Currently, Teiid Spring Boot uses LRU based cache as default caching layer, this should be replaced with [caffeine|https://github.com/ben-manes/caffeine]



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 12:55:07 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 15 Jan 2019 12:55:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't
 accept NVARCHAR type
In-Reply-To: <JIRA.12786388.1546881713000@Atlassian.JIRA>
References: <JIRA.12786388.1546881713000@Atlassian.JIRA>
	<JIRA.12786388.1546881713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786388.1546881713000.82872.1547574907182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5587:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> Oracle 11 drivers don't accept NVARCHAR type
> --------------------------------------------
>
>                 Key: TEIID-5587
>                 URL: https://issues.jboss.org/browse/TEIID-5587
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDBC Connector
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 8.12.17.6_4, 11.2.2
>
>
> Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like:
> {code}
> Caused by: java.sql.SQLException: Invalid column type
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577)
> 	at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286)
> 	at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548)
> 	at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145)
> {code}
> We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 13:08:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 15 Jan 2019 13:08:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.82992.1547575680521@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy resolved TEIID-5590.
---------------------------------
    Fix Version/s: 12.0
                       (was: 12.x)
       Resolution: Done


Re-introduced processing of resources into the plugin as it was easier workflow, otherwise, the user needs to create a new directory called "uberresources" that will be picked by the Thorntail maven plugin as resources file. Since it is additional work on user + additional knowledge needs to acquired by the user, even though it does not make sense to put the properties file/yml file in .vdb artifact as it works exactly same otherwise.

This change is in 1.4 release of vdb-maven-plugin

> vdb-maven-plugin - version 1.3 breaks build lifecycle
> -----------------------------------------------------
>
>                 Key: TEIID-5590
>                 URL: https://issues.jboss.org/browse/TEIID-5590
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits, VDB
>         Environment: {code}
> 2019-01-08 15:49:30
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
> Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
> 2019-01-08 15:52:36
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
> Maven home: /opt/maven
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
> 2019-01-08 15:52:40
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
> openjdk version "1.8.0_192"
> OpenJDK Runtime Environment (build 1.8.0_192-b26)
> OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
> {code}
>            Reporter: G. Richard Bellamy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.0
>
>
> When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
> {code}
> [INFO] 'package' is a phase corresponding to this plugin:
> org.teiid:vdb-maven-plugin:vdb
> It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
> * validate: Not defined
> * initialize: Not defined
> * generate-sources: Not defined
> * process-sources: Not defined
> * generate-resources: Not defined
> * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
> * compile: org.apache.maven.plugins:maven-compiler-plugin:compile
> * process-classes: Not defined
> * generate-test-sources: Not defined
> * process-test-sources: Not defined
> * generate-test-resources: Not defined
> * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
> * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
> * process-test-classes: Not defined
> * test: org.apache.maven.plugins:maven-surefire-plugin:test
> * prepare-package: Not defined
> * package: org.teiid:vdb-maven-plugin:vdb
> * pre-integration-test: Not defined
> * integration-test: Not defined
> * post-integration-test: Not defined
> * verify: Not defined
> * install: org.apache.maven.plugins:maven-install-plugin:install
> * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 14:53:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 14:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5595) Solve the maven duplicate
 PartSupplier.vdb issue
In-Reply-To: <JIRA.12787139.1547217277000@Atlassian.JIRA>
References: <JIRA.12787139.1547217277000@Atlassian.JIRA>
	<JIRA.12787139.1547217277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787139.1547217277000.84059.1547581980252@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert updated TEIID-5595:
-------------------------------
    Git Pull Request: https://github.com/teiid/teiid/pull/1125


> Solve the maven duplicate PartSupplier.vdb issue
> ------------------------------------------------
>
>                 Key: TEIID-5595
>                 URL: https://issues.jboss.org/browse/TEIID-5595
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Trivial
>
> When changing to use the basebom, it triggered a duplicate artifiact issue with PartsSupplier.vdb between the metadata project and the connector projects.   If its the exact same vdb, then the connector vdb could be removed.  Otherwise, I would suggest the connectors rename their vdb and fix the related dependent tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 15:07:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 15:07:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5604) Issue with javadoc plugin
In-Reply-To: <JIRA.12787587.1547582792000@Atlassian.JIRA>
References: <JIRA.12787587.1547582792000@Atlassian.JIRA>
	<JIRA.12787587.1547582792475@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787587.1547582792000.84160.1547582820806@Atlassian.JIRA>

Steven Hawkins created TEIID-5604:
-------------------------------------

             Summary: Issue with javadoc plugin
                 Key: TEIID-5604
                 URL: https://issues.jboss.org/browse/TEIID-5604
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


With the 12.0.0 release it was missed that version.javadoc.plugin was not set in the root pom.xml - it had previously come from jboss parent.  Using either the new version 3.0.1 or the old 2.10.4 (from the 11.2 jboss parent) results in a lot of javadoc issues that were previously ignored.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 15:22:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 15:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5604) Issue with javadoc plugin
In-Reply-To: <JIRA.12787587.1547582792000@Atlassian.JIRA>
References: <JIRA.12787587.1547582792000@Atlassian.JIRA>
	<JIRA.12787587.1547582792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787587.1547582792000.84284.1547583720821@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682588#comment-13682588 ] 

Steven Hawkins commented on TEIID-5604:
---------------------------------------

For now I'll just use mvn javadoc:aggregate -Dmaven.javadoc.failOnError=false

But ideally we back that into the plugin config or try to fix the errors.


> Issue with javadoc plugin
> -------------------------
>
>                 Key: TEIID-5604
>                 URL: https://issues.jboss.org/browse/TEIID-5604
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> With the 12.0.0 release it was missed that version.javadoc.plugin was not set in the root pom.xml - it had previously come from jboss parent.  Using either the new version 3.0.1 or the old 2.10.4 (from the 11.2 jboss parent) results in a lot of javadoc issues that were previously ignored.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 15:22:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 15:22:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5590) vdb-maven-plugin - version
 1.3 breaks build lifecycle
In-Reply-To: <JIRA.12786661.1546992578000@Atlassian.JIRA>
References: <JIRA.12786661.1546992578000@Atlassian.JIRA>
	<JIRA.12786661.1546992578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786661.1546992578000.84288.1547583722257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5590:
----------------------------------
    Fix Version/s:     (was: 12.0)


> vdb-maven-plugin - version 1.3 breaks build lifecycle
> -----------------------------------------------------
>
>                 Key: TEIID-5590
>                 URL: https://issues.jboss.org/browse/TEIID-5590
>             Project: Teiid
>          Issue Type: Bug
>          Components: Build/Kits, VDB
>         Environment: {code}
> 2019-01-08 15:49:30
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % uname -a
> Linux eanna 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
> 2019-01-08 15:52:36
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % mvn -v
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root; 2018-09-07T16:02:16-07:00)
> Maven home: /opt/maven
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.20.0-arch1-1-arch", arch: "amd64", family: "unix"
> 2019-01-08 15:52:40
> rbellamy at eanna i ~/Development/Terradatum/metrics-vdb master % java -version
> openjdk version "1.8.0_192"
> OpenJDK Runtime Environment (build 1.8.0_192-b26)
> OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)
> {code}
>            Reporter: G. Richard Bellamy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> When building a VDB with version 1.3 of the vdb-maven-plugin, the {{src/main/resources}} directory is NOT processed as expected. When using version 1.1, the "package" phase has the following (correct) phases:
> {code}
> [INFO] 'package' is a phase corresponding to this plugin:
> org.teiid:vdb-maven-plugin:vdb
> It is a part of the lifecycle for the POM packaging 'vdb'. This lifecycle includes the following phases:
> * validate: Not defined
> * initialize: Not defined
> * generate-sources: Not defined
> * process-sources: Not defined
> * generate-resources: Not defined
> * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources
> * compile: org.apache.maven.plugins:maven-compiler-plugin:compile
> * process-classes: Not defined
> * generate-test-sources: Not defined
> * process-test-sources: Not defined
> * generate-test-resources: Not defined
> * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources
> * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile
> * process-test-classes: Not defined
> * test: org.apache.maven.plugins:maven-surefire-plugin:test
> * prepare-package: Not defined
> * package: org.teiid:vdb-maven-plugin:vdb
> * pre-integration-test: Not defined
> * integration-test: Not defined
> * post-integration-test: Not defined
> * verify: Not defined
> * install: org.apache.maven.plugins:maven-install-plugin:install
> * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 15:26:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 15:26:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5559) odata4 NPE when accessing
 VDB including FK relationship across models
In-Reply-To: <JIRA.12782132.1543861861000@Atlassian.JIRA>
References: <JIRA.12782132.1543861861000@Atlassian.JIRA>
	<JIRA.12782132.1543861861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782132.1543861861000.84317.1547583962642@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682595#comment-13682595 ] 

Steven Hawkins commented on TEIID-5559:
---------------------------------------

[~jolee] I'll take a pass at this.

> odata4 NPE when accessing VDB including FK relationship across models
> ---------------------------------------------------------------------
>
>                 Key: TEIID-5559
>                 URL: https://issues.jboss.org/browse/TEIID-5559
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Marc Shirley
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.1
>
>
> Receive error [2] when attempting to access table that utilizes a foreign key to another model with URL like [1].  access to the other model (that the foreign key references) works correctly.
> [1] http://127.0.0.1:8080/odata4/fktest/fkmodel/
> [2] 
> JBWEB000309: type JBWEB000066: Exception report
> JBWEB000068: message 
> JBWEB000069: description JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.
> JBWEB000070: exception 
> org.teiid.core.TeiidRuntimeException
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildMetadata(ODataSchemaBuilder.java:58)
> 	org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:54)
> 	org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:228)
> 	org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100)
> 	org.teiid.olingo.web.CorsFilter.doFilter(CorsFilter.java:80)
> JBWEB000071: root cause 
> java.lang.NullPointerException
> 	org.teiid.olingo.service.ODataSchemaBuilder.addReverseNavigation(ODataSchemaBuilder.java:308)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildNavigationProperties(ODataSchemaBuilder.java:251)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildEntityTypes(ODataSchemaBuilder.java:144)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildMetadata(ODataSchemaBuilder.java:54)
> 	org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:54)
> 	org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:228)
> 	org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100)
> 	org.teiid.olingo.web.CorsFilter.doFilter(CorsFilter.java:80)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:13:09 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 16:13:09 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.84750.1547586789006@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5594 started by Van Halbert.
------------------------------------------
> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:26:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 16:26:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5541) Incorrect parsing of xml
	with XmlTable
In-Reply-To: <JIRA.12779404.1542211749000@Atlassian.JIRA>
References: <JIRA.12779404.1542211749000@Atlassian.JIRA>
	<JIRA.12779404.1542211749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779404.1542211749000.84854.1547587560605@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682674#comment-13682674 ] 

Steven Hawkins commented on TEIID-5541:
---------------------------------------

[~jolee] See https://github.com/shawkins/teiid/tree/64-8.12.x

> Incorrect parsing of xml with XmlTable
> --------------------------------------
>
>                 Key: TEIID-5541
>                 URL: https://issues.jboss.org/browse/TEIID-5541
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 11.1
>         Environment: teiid-11.1.0 (from 01.09.2018) on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
>            Reporter: dalex dalex
>            Assignee: Steven Hawkins
>            Priority: Blocker
>             Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1
>
>
> Running the query:
> {code:sql}
> Begin
> 	Declare xml xcontent = '<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> 	<report>
> 		<data>
> 			<year xsi:type="decimal">2018</year>
> 		</data>
> 	</report>
> 	<waitSeconds xsi:type="decimal">13</waitSeconds>
>      </root>' ;
> 	Select *
> 	From 
> 		XmlTable(
> 			XmlNamespaces ('http://www.w3.org/2001/XMLSchema-instance' as xsi),
> 			'/root/report/data' 
> 			PASSING xcontent 
> 			Columns 
> 				"year" integer,
> 				waitSeconds xml Path 'root()/root/waitSeconds',
> 				waitSecondsStr string Path 'root()/root/waitSeconds'
> 	)a ;
> End ;;
> {code}
> and having a look at the structure we can see that the value 13 should be returned, while the value is not picked from xml for result.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:28:08 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 16:28:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5605) widenUnsignedTypes does
 not account for long/bigint
In-Reply-To: <JIRA.12787594.1547587654000@Atlassian.JIRA>
References: <JIRA.12787594.1547587654000@Atlassian.JIRA>
	<JIRA.12787594.1547587654985@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787594.1547587654000.84876.1547587688590@Atlassian.JIRA>

Steven Hawkins created TEIID-5605:
-------------------------------------

             Summary: widenUnsignedTypes does not account for long/bigint
                 Key: TEIID-5605
                 URL: https://issues.jboss.org/browse/TEIID-5605
             Project: Teiid
          Issue Type: Quality Risk
          Components: JDG Connector
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


An unsigned long/bigint from a database will still be mapped to a teiid long - which will have issues with values above max_long.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:31:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 15 Jan 2019 16:31:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.84954.1547587861275@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682677#comment-13682677 ] 

Van Halbert commented on TEIID-5594:
------------------------------------

regarding:
{code}
               <groupId>org.jboss.spec.javax.xml.bind</groupId>
               <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
{code}
replacing with bom:
{code}
                <groupId>org.glassfish.jaxb</groupId>
                <artifactId>jaxb-bom</artifactId>
                <version>2.3.1</version>
                <type>pom</type>
                <scope>import</scope>
{code}
with dependencies
{code}
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-jxc</artifactId> 
{code}

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:37:02 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 15 Jan 2019 16:37:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5559) odata4 NPE when accessing
 VDB including FK relationship across models
In-Reply-To: <JIRA.12782132.1543861861000@Atlassian.JIRA>
References: <JIRA.12782132.1543861861000@Atlassian.JIRA>
	<JIRA.12782132.1543861861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782132.1543861861000.84995.1547588222917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5559:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> odata4 NPE when accessing VDB including FK relationship across models
> ---------------------------------------------------------------------
>
>                 Key: TEIID-5559
>                 URL: https://issues.jboss.org/browse/TEIID-5559
>             Project: Teiid
>          Issue Type: Bug
>          Components: OData
>    Affects Versions: 8.12.16.6_4
>            Reporter: Marc Shirley
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0, 11.2.1, 8.12.17.6_4
>
>
> Receive error [2] when attempting to access table that utilizes a foreign key to another model with URL like [1].  access to the other model (that the foreign key references) works correctly.
> [1] http://127.0.0.1:8080/odata4/fktest/fkmodel/
> [2] 
> JBWEB000309: type JBWEB000066: Exception report
> JBWEB000068: message 
> JBWEB000069: description JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.
> JBWEB000070: exception 
> org.teiid.core.TeiidRuntimeException
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildMetadata(ODataSchemaBuilder.java:58)
> 	org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:54)
> 	org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:228)
> 	org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100)
> 	org.teiid.olingo.web.CorsFilter.doFilter(CorsFilter.java:80)
> JBWEB000071: root cause 
> java.lang.NullPointerException
> 	org.teiid.olingo.service.ODataSchemaBuilder.addReverseNavigation(ODataSchemaBuilder.java:308)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildNavigationProperties(ODataSchemaBuilder.java:251)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildEntityTypes(ODataSchemaBuilder.java:144)
> 	org.teiid.olingo.service.ODataSchemaBuilder.buildMetadata(ODataSchemaBuilder.java:54)
> 	org.teiid.olingo.service.OlingoBridge.getHandler(OlingoBridge.java:54)
> 	org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:228)
> 	org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100)
> 	org.teiid.olingo.web.CorsFilter.doFilter(CorsFilter.java:80)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 16:51:01 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Tue, 15 Jan 2019 16:51:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5541) Incorrect parsing of xml
	with XmlTable
In-Reply-To: <JIRA.12779404.1542211749000@Atlassian.JIRA>
References: <JIRA.12779404.1542211749000@Atlassian.JIRA>
	<JIRA.12779404.1542211749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779404.1542211749000.85045.1547589061315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-5541:
---------------------------------
    Fix Version/s: 8.12.17.6_4


> Incorrect parsing of xml with XmlTable
> --------------------------------------
>
>                 Key: TEIID-5541
>                 URL: https://issues.jboss.org/browse/TEIID-5541
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 11.1
>         Environment: teiid-11.1.0 (from 01.09.2018) on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
>            Reporter: dalex dalex
>            Assignee: Steven Hawkins
>            Priority: Blocker
>             Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1, 8.12.17.6_4
>
>
> Running the query:
> {code:sql}
> Begin
> 	Declare xml xcontent = '<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> 	<report>
> 		<data>
> 			<year xsi:type="decimal">2018</year>
> 		</data>
> 	</report>
> 	<waitSeconds xsi:type="decimal">13</waitSeconds>
>      </root>' ;
> 	Select *
> 	From 
> 		XmlTable(
> 			XmlNamespaces ('http://www.w3.org/2001/XMLSchema-instance' as xsi),
> 			'/root/report/data' 
> 			PASSING xcontent 
> 			Columns 
> 				"year" integer,
> 				waitSeconds xml Path 'root()/root/waitSeconds',
> 				waitSecondsStr string Path 'root()/root/waitSeconds'
> 	)a ;
> End ;;
> {code}
> and having a look at the structure we can see that the value 13 should be returned, while the value is not picked from xml for result.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 17:12:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 17:12:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5601) OData needs to account for
 source order and org.teiid.defaultNullOrder
In-Reply-To: <JIRA.12787374.1547490824000@Atlassian.JIRA>
References: <JIRA.12787374.1547490824000@Atlassian.JIRA>
	<JIRA.12787374.1547490824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787374.1547490824000.85071.1547590320230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5601.
-----------------------------------
    Resolution: Done


Added explicit null ordering with the $orderby parameter.  I did not add null ordering to the default order as that will typically not involve nulls - but there may be a corner case that eventually needs addressed.

> OData needs to account for source order and org.teiid.defaultNullOrder
> ----------------------------------------------------------------------
>
>                 Key: TEIID-5601
>                 URL: https://issues.jboss.org/browse/TEIID-5601
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> Teiid's default null handling (low) matches that of the odata spec.  However we don't have strict enforcement that pushdown order bys must match that ordering - only an option to do so if it's supported by the source org.teiid.pushdownDefaultOrderBy.  We also have  org.teiid.defaultNullOrder which can be set to something other than low.  In either of those cases the returned ordering will not match the spec: http://docs.oasis-open.org/odata/odata/v4.01/cs01/part1-protocol/odata-v4.01-cs01-part1-protocol.html#_Toc505771210



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 20:03:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 20:03:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5595) Solve the maven duplicate
 PartSupplier.vdb issue
In-Reply-To: <JIRA.12787139.1547217277000@Atlassian.JIRA>
References: <JIRA.12787139.1547217277000@Atlassian.JIRA>
	<JIRA.12787139.1547217277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787139.1547217277000.85263.1547600580622@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5595:
----------------------------------
    Fix Version/s: 12.1


> Solve the maven duplicate PartSupplier.vdb issue
> ------------------------------------------------
>
>                 Key: TEIID-5595
>                 URL: https://issues.jboss.org/browse/TEIID-5595
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Trivial
>             Fix For: 12.1
>
>
> When changing to use the basebom, it triggered a duplicate artifiact issue with PartsSupplier.vdb between the metadata project and the connector projects.   If its the exact same vdb, then the connector vdb could be removed.  Otherwise, I would suggest the connectors rename their vdb and fix the related dependent tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 15 20:57:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 15 Jan 2019 20:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.85287.1547603820384@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682709#comment-13682709 ] 

Steven Hawkins commented on TEIID-5593:
---------------------------------------

>From the build and the docs confirm that matrix is in addition to any combination of jobs created by the runtime/environment.  So I've made a couple of changes to remove the matrix, and to update the pom to not run the arquillian tests when running java 11 - that makes the travis file a little simpler.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 08:26:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 08:26:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5593) Add a Java 11 travis build
In-Reply-To: <JIRA.12787120.1547213462000@Atlassian.JIRA>
References: <JIRA.12787120.1547213462000@Atlassian.JIRA>
	<JIRA.12787120.1547213462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787120.1547213462000.99775.1547645163998@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5593.
-----------------------------------
    Fix Version/s: 12.0.1
       Resolution: Done


Merged Van's commit and updated the arquillian tests to not run at all for java 11+.  We'll revisit that in Teiid 13.

> Add a Java 11 travis build
> --------------------------
>
>                 Key: TEIID-5593
>                 URL: https://issues.jboss.org/browse/TEIID-5593
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1, 12.0.1
>
>
> We should also build/test with java 11 on travis.  This is expected to work for everything but the arquillian tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 09:36:11 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 09:36:11 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.108892.1547649371461@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5599 started by Steven Hawkins.
---------------------------------------------
> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 09:36:15 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 09:36:15 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.108909.1547649375826@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683016#comment-13683016 ] 

Van Halbert edited comment on TEIID-5594 at 1/16/19 9:27 AM:
-------------------------------------------------------------

regarding:
{code}
               <groupId>org.jboss.spec.javax.transaction</groupId>
               <artifactId>jboss-transaction-api_1.2_spec</artifactId>
               <version>1.1.1.Final</version>
{code}
replacing with:
{code}
               <groupId>javax.transaction</groupId>
               <artifactId>javax.transaction-api</artifactId>
               <version>1.3</version>
{code}


was (Author: van.halbert):
regarding:
{code}
               <groupId>org.jboss.spec.javax.transaction</groupId>
               <artifactId>jboss-transaction-api_1.2_spec</artifactId>
               <version>1.1.1.Final</version>
{code}
replacing with bom:
{code}
               <groupId>javax.transaction</groupId>
               <artifactId>javax.transaction-api</artifactId>
               <version>1.3</version>
{code}

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 10:51:28 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 10:51:28 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.114683.1547653888870@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683077#comment-13683077 ] 

Van Halbert commented on TEIID-5594:
------------------------------------

regarding:
{code}
               <groupId>org.jboss.spec.javax.xml.ws</groupId>
               <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
               <version>1.0.0.Final</version>
{code}
replacing with bom:
{code}
                <groupId>javax.xml.ws</groupId>
                <artifactId>jaxws-api</artifactId>
                <version>2.3.1</version>
{code}

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 10:51:30 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 10:51:30 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.114689.1547653890370@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683076#comment-13683076 ] 

Steven Hawkins commented on TEIID-5599:
---------------------------------------

This is coming from the Account condition.  I should be able to produce a better error message for that though.

If you don't need it enforced for the insert, set the constraint flag to false - see http://teiid.github.io/teiid-documents/master/content/reference/Permissions.html Role Based Security and the example on http://teiid.github.io/teiid-documents/master/content/reference/XML_Definition.html - if you do that, you should be able to confirm that your scenario works.

However this is generally a bug - we should evaluate the condition even without the idProfile.

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 10:57:00 2019
From: issues at jboss.org (Christoph John (Jira))
Date: Wed, 16 Jan 2019 10:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.114773.1547654220173@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683089#comment-13683089 ] 

Christoph John commented on TEIID-5599:
---------------------------------------

Hello Steven, 
thanks for the info.

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 12:02:06 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 12:02:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5606) Deprecate
	project-integration-bom repo
In-Reply-To: <JIRA.12787768.1547657963000@Atlassian.JIRA>
References: <JIRA.12787768.1547657963000@Atlassian.JIRA>
	<JIRA.12787768.1547657963271@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787768.1547657963000.117733.1547658126631@Atlassian.JIRA>

Van Halbert created TEIID-5606:
----------------------------------

             Summary: Deprecate project-integration-bom repo
                 Key: TEIID-5606
                 URL: https://issues.jboss.org/browse/TEIID-5606
             Project: Teiid
          Issue Type: Task
            Reporter: Van Halbert
            Assignee: Steven Hawkins


Deprecate the project-integration-bom repo.   Now that its no longer referenced in 12.x or 11.2, this repo should be flagged as no longer being used.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 12:18:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 12:18:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.119217.1547659080112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683138#comment-13683138 ] 

Van Halbert commented on TEIID-5594:
------------------------------------

regarding:
{code}
               <groupId>org.jboss.spec.javax.servlet</groupId>
               <artifactId>jboss-servlet-api_3.1_spec</artifactId>
               <version>1.0.2.Final</version>
{code}
replacing with bom:
{code}
                <groupId>javax.servlet</groupId>
                <artifactId>javax.servlet-api</artifactId>
                <version>4.0.1</version>
{code}

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 12:18:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 12:18:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5599) When creating an entity
 via POST message, it is expected,
 that the returned message includes the primary key of the newly created
 instance. This is not the case currently
In-Reply-To: <JIRA.12787366.1547486704000@Atlassian.JIRA>
References: <JIRA.12787366.1547486704000@Atlassian.JIRA>
	<JIRA.12787366.1547486704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787366.1547486704000.119235.1547659084784@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5599.
-----------------------------------
    Fix Version/s: 11.2.2
                   12.0.1
       Resolution: Done


Updated the logic to check whether a missing value is used in the checked condition or not and provide a more informative error if it is.

> When creating an entity via POST message, it is expected, that the returned message includes the primary key of the newly created instance. This is not the case currently
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5599
>                 URL: https://issues.jboss.org/browse/TEIID-5599
>             Project: Teiid
>          Issue Type: Bug
>            Reporter: Christoph John
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> The following communication shows the issue. What I am doing here is to create a new Account entity via post request. My underlaying mysql database requires the primary key in the table to be set to NN (not null), hence, a value must be provided. Moreover the primary key is set to autoincrement and is generated by the database. The only execepted value here seems to be, to provide the key with value=0. The object is created in the database as expected. However, Teiid answers with the created object, but again with the primary key (idProfile) set as zero, instead to provide the newly created primary key.
> POST Account HTTP/1.1
> Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
> Accept-Language:de-DE
> Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
> {"uuidUser":"65820574-7525-463b-9d20-5ee133a06b94","idProfile":"0"}
> --batch_id-1547485733072-21
> Content-Type:application/http
> Content-Transfer-Encoding:binary
> The response:
> HTTP/1.1 201 Created
> Location: http://localhost/odata4/svc/my_nutri_diary/Account(0)
> Content-Type: application/json;ieee754compatible=true;odata.metadata=minimal
> Content-Length: 147
> {"@odata.context":"http://localhost/odata4/svc/my_nutri_diary/$metadata#Account","idProfile":"0","uuidUser":"65820574-7525-463b-9d20-5ee133a06b94"}
> --batch_e834eb7c-df0d-4e22-a423-78cd3638955f
> Content-Type: application/http
> Content-Transfer-Encoding: binary



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 13:00:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 13:00:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5595) Solve the maven duplicate
 PartSupplier.vdb issue
In-Reply-To: <JIRA.12787139.1547217277000@Atlassian.JIRA>
References: <JIRA.12787139.1547217277000@Atlassian.JIRA>
	<JIRA.12787139.1547217277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787139.1547217277000.120133.1547661601753@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5595.
-----------------------------------
    Resolution: Done


Merged Van's PR, which just renamed the one of them.  We may want to consider differentiating between stuff that gets into the classpath and stuff that's used from the file system - currently even if we only use file references to get at stuff in test resources, they will end up in the test-jar.

> Solve the maven duplicate PartSupplier.vdb issue
> ------------------------------------------------
>
>                 Key: TEIID-5595
>                 URL: https://issues.jboss.org/browse/TEIID-5595
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Trivial
>             Fix For: 12.1
>
>
> When changing to use the basebom, it triggered a duplicate artifiact issue with PartsSupplier.vdb between the metadata project and the connector projects.   If its the exact same vdb, then the connector vdb could be removed.  Otherwise, I would suggest the connectors rename their vdb and fix the related dependent tests.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 13:00:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 13:00:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5606) Deprecate
	project-integration-bom repo
In-Reply-To: <JIRA.12787768.1547657963000@Atlassian.JIRA>
References: <JIRA.12787768.1547657963000@Atlassian.JIRA>
	<JIRA.12787768.1547657963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787768.1547657963000.120135.1547661602158@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5606:
----------------------------------
    Fix Version/s: 12.1


> Deprecate project-integration-bom repo
> --------------------------------------
>
>                 Key: TEIID-5606
>                 URL: https://issues.jboss.org/browse/TEIID-5606
>             Project: Teiid
>          Issue Type: Task
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Deprecate the project-integration-bom repo.   Now that its no longer referenced in 12.x or 11.2, this repo should be flagged as no longer being used.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 14:13:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 14:13:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.121011.1547665982951@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683165#comment-13683165 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

Core should also be reserved.  

To reproduce the problem, use a schema named teiid, then exceptions will arise when fetching the metadata as the annotation terms will no longer be known.


> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 15:45:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 15:45:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.123068.1547671500857@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683272#comment-13683272 ] 

Van Halbert commented on TEIID-5594:
------------------------------------

regarding:
{code}
               <groupId>org.slf4j</groupId>
               <artifactId>slf4j-api</artifactId>
               <version>1.7.22.jbossorg-1</version>
{code}
replacing with bom:
{code}
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.11.1</version>
{code}

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 15:45:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 15:45:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.123070.1547671501263@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5594 stopped by Van Halbert.
------------------------------------------
> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 15:46:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 16 Jan 2019 15:46:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.123086.1547671560248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert updated TEIID-5594:
-------------------------------
    Git Pull Request: https://github.com/teiid/teiid/pull/1126


> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 16:28:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 16:28:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.126466.1547674082716@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683341#comment-13683341 ] 

Steven Hawkins edited comment on TEIID-5561 at 1/16/19 4:25 PM:
----------------------------------------------------------------

URL reserved characters are a problem also.  The odata filter uses non decoded string to determine the vdb, version, and schema.  I can't really find a reference in the odata spec as to the expectation or limitation on schema names.


was (Author: shawkins):
URL reserved characters are a problem also.  The odata filter uses httpRequest.getContextPath() to determine the vdb, version, and schema - but that url is not decoded.  I can't really find a reference in the odata spec as to the expectation or limitation on schema names.

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 16:28:07 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 16:28:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.126486.1547674087407@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683341#comment-13683341 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

URL reserved characters are a problem also.  The odata filter uses httpRequest.getContextPath() to determine the vdb, version, and schema - but that url is not decoded.  I can't really find a reference in the odata spec as to the expectation or limitation on schema names.

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 16:54:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 16:54:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.126667.1547675641163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683348#comment-13683348 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

For the vdb/model name there is a straight-forward fix.  olingo already handles decoding, but it does not like having the meta characters / $ & etc. as part of the entity names.

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 17:51:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 16 Jan 2019 17:51:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.126902.1547679060793@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683357#comment-13683357 ] 

Ramesh Reddy commented on TEIID-5561:
-------------------------------------

They identify all names conform to what is referred to as "odataIdentifier". The below is ABNF form

{code}
odataIdentifier             = identifierLeadingCharacter *127identifierCharacter
identifierLeadingCharacter  = ALPHA / "_"         ; plus Unicode characters from the categories L or Nl
identifierCharacter         = ALPHA / "_" / DIGIT ; plus Unicode characters from the categories L, Nl, Nd, Mn, Mc, Pc, or Cf
{code}

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 21:03:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 16 Jan 2019 21:03:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.127005.1547690580524@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683373#comment-13683373 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

Thanks.  Forgot to check the ABNF.  That clarifies what is expected.  Using the referenced TSimpleIdentifier pattern confirms that most non-letter characters are not accepted.  That is a problem for us in that it's much more restrictive than SQL identifiers.  The olingo metadata layer does not apply any restrictions, so we can create invalid metadata that is not queryable.  It is possible to choose a naming replacement strategy similar to what is done with sql/xml names, but that will be a big change at first glance given our assumptions about the 1-1 mapping between odata and teiid metadata names.  

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 16 21:45:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 16 Jan 2019 21:45:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.127038.1547693100552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683378#comment-13683378 ] 

Ramesh Reddy commented on TEIID-5561:
-------------------------------------

I am fine side of erroring as we have not seen this case yet and it has easy ways ways to workaround in Teiid.

The most problematic char is period imo

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 08:19:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 08:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.145717.1547731140291@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683632#comment-13683632 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

> The most problematic char is period imo

Yes that one occurs commonly in both table and even column names.  If I address that, I should be able to address everything though.  I'll see what's possible.

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 10:11:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 10:11:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5608) General code formatting
In-Reply-To: <JIRA.12787925.1547737804000@Atlassian.JIRA>
References: <JIRA.12787925.1547737804000@Atlassian.JIRA>
	<JIRA.12787925.1547737804663@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787925.1547737804000.153737.1547737860195@Atlassian.JIRA>

Steven Hawkins created TEIID-5608:
-------------------------------------

             Summary: General code formatting
                 Key: TEIID-5608
                 URL: https://issues.jboss.org/browse/TEIID-5608
             Project: Teiid
          Issue Type: Task
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 13.0


It would be good to add hard checkstyle formatting checks (in particular tabs) in the build, but first we need to take a pass through to clean up things. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 12:28:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 12:28:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.161778.1547746080176@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683787#comment-13683787 ] 

Steven Hawkins commented on TEIID-5561:
---------------------------------------

> So far we have been avoiding it by not using the qualified names. which is working so far.

That only works by separating out the schema.  It does not work if the table name actually contains '.'.  So I can:

1. Add validations and logs when a table / column name is not valid - we could also add an annotation to the metadata, but I didn't do that just yet.
2. Update all of the schema and sql construction logic to allow for some escaping mechanism, such that any name could be supported - which is a fairly involved change.  Alternatively there would need to be some kind of intermediate virtual metadata layer that does the appropriate cleanup.

For now I'll just do 1 and call it a day.

Throwing an error is possible, but it may inadvertently break some cases so I won't do that for now.

Similarly excluding the table / column leads to all kinds of other issues with the logic given our base expectations that anything with a unique / pk is available.


> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 12:42:08 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 12:42:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5561) Prevent alias collisions
 with built-in odata schema
In-Reply-To: <JIRA.12782379.1543962555000@Atlassian.JIRA>
References: <JIRA.12782379.1543962555000@Atlassian.JIRA>
	<JIRA.12782379.1543962555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12782379.1543962555000.161958.1547746928229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5561.
-----------------------------------
    Resolution: Done


Where things stand:

- schema names will no longer collide with built-in aliases
- schema / vdb names will be decoded.  non-letter character letters are allowed by the our odata filter logic - which at least for the schema name is against the spec.
- we'll log a detail message when a table / procedure / column etc. name is not valid wrt odata.  The metadata will still be constructed as per usual, but the object in question won't be queryable.
- there was some clean-up of unused methods, and logic around names to start to add more consistency.

> Prevent alias collisions with built-in odata schema
> ---------------------------------------------------
>
>                 Key: TEIID-5561
>                 URL: https://issues.jboss.org/browse/TEIID-5561
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: OData
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> It is problematic to have a Teiid model/schema with the name:
> olingo-extensions
> teiid
> edm
> as that will use an alias that conflicts with built-in handling.  We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 13:37:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 13:37:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5580) Support: MongoDB 4.0
In-Reply-To: <JIRA.12785455.1545319817000@Atlassian.JIRA>
References: <JIRA.12785455.1545319817000@Atlassian.JIRA>
	<JIRA.12785455.1545319817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12785455.1545319817000.162566.1547750223735@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5580 started by Steven Hawkins.
---------------------------------------------
> Support: MongoDB 4.0
> --------------------
>
>                 Key: TEIID-5580
>                 URL: https://issues.jboss.org/browse/TEIID-5580
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.12.16.6_4
>            Reporter: Colin Mondesir
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> According to the MongoDB 4.0  docs [1] the minimum driver version required is 3.80 Currently Teiid 8.12 is using 2.13
> 1 https://docs.mongodb.com/manual/release-notes/4.0/#drivers



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 16:06:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Thu, 17 Jan 2019 16:06:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.164223.1547759160459@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683858#comment-13683858 ] 

Ramesh Reddy commented on TEIID-5521:
-------------------------------------

It looks like basebom turns off the javadoc for the build. This needs to be turned back on for the release profile otherwise when you push to maven central it will fail.

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 16:42:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 16:42:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2957) MongoDB: Implement
 Compensating transactions
In-Reply-To: <JIRA.12540694.1400000365000@Atlassian.JIRA>
References: <JIRA.12540694.1400000365000@Atlassian.JIRA>
	<JIRA.12540694.1400000365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540694.1400000365000.165060.1547761320280@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-2957 started by Steven Hawkins.
---------------------------------------------
> MongoDB: Implement Compensating transactions
> --------------------------------------------
>
>                 Key: TEIID-2957
>                 URL: https://issues.jboss.org/browse/TEIID-2957
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.5
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Based on Narayana transaction manager, which is the TM that JBoss EAP TM based on one can build compensating transactions over MongoDB
> https://github.com/jbosstm/quickstart/blob/master/compensating-transactions/mongodb-simple/pom.xml
> https://plus.google.com/wm/1/events/cnbaif9aiiaarnjtd047nt1pksc
> Need to see the version number matches then need to buiild the necessary framework around mongodb translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 16:51:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 17 Jan 2019 16:51:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.165087.1547761860522@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683868#comment-13683868 ] 

Van Halbert commented on TEIID-5521:
------------------------------------

I assume release, you mean the final-release profile.  I'll add the following:

{code}
            <properties>
                <basepom.check.skip-javadoc>false</basepom.check.skip-javadoc>
         </properties>
{code}

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 16:59:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 17 Jan 2019 16:59:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2957) MongoDB: Implement
 Compensating transactions
In-Reply-To: <JIRA.12540694.1400000365000@Atlassian.JIRA>
References: <JIRA.12540694.1400000365000@Atlassian.JIRA>
	<JIRA.12540694.1400000365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540694.1400000365000.165110.1547762340508@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683871#comment-13683871 ] 

Steven Hawkins commented on TEIID-2957:
---------------------------------------

The easiest approach here would be something like a 1-pc LocalTransaction resource.  I'll see how hard that would be to wire into the RA.  

We can use https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/MongoTransactionManager.java for reference.

Just trying to handle this in the translator could be possible, but would intertwine some transactional concerns.  We'd have to detect a transaction on the thread, then create the mongo client session and attach a synchronization to the txn to do the final commit / rollback - so still effectively 1-pc.  Another drawback is that code is generally not needed for environments like springboot, which would instead use the transactionmanager above or some kind of composite with other platform transaction managers.

> MongoDB: Implement Compensating transactions
> --------------------------------------------
>
>                 Key: TEIID-2957
>                 URL: https://issues.jboss.org/browse/TEIID-2957
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.5
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Based on Narayana transaction manager, which is the TM that JBoss EAP TM based on one can build compensating transactions over MongoDB
> https://github.com/jbosstm/quickstart/blob/master/compensating-transactions/mongodb-simple/pom.xml
> https://plus.google.com/wm/1/events/cnbaif9aiiaarnjtd047nt1pksc
> Need to see the version number matches then need to buiild the necessary framework around mongodb translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 17 17:00:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 17 Jan 2019 17:00:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5521) Add build plugins used by
 basepom to help with dependency handling
In-Reply-To: <JIRA.12776315.1540475681000@Atlassian.JIRA>
References: <JIRA.12776315.1540475681000@Atlassian.JIRA>
	<JIRA.12776315.1540475681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776315.1540475681000.165116.1547762400459@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683868#comment-13683868 ] 

Van Halbert edited comment on TEIID-5521 at 1/17/19 4:59 PM:
-------------------------------------------------------------

I assume release, you mean the final-release profile.  I'll add the following:

{code}
            <properties>
                <basepom.check.skip-javadoc>false</basepom.check.skip-javadoc>
         </properties>
{code}

updated my teiid-5521 branch.


was (Author: van.halbert):
I assume release, you mean the final-release profile.  I'll add the following:

{code}
            <properties>
                <basepom.check.skip-javadoc>false</basepom.check.skip-javadoc>
         </properties>
{code}

> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
>                 Key: TEIID-5521
>                 URL: https://issues.jboss.org/browse/TEIID-5521
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 18 11:38:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 18 Jan 2019 11:38:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5612) Switch to auto release
In-Reply-To: <JIRA.12788139.1547829474000@Atlassian.JIRA>
References: <JIRA.12788139.1547829474000@Atlassian.JIRA>
	<JIRA.12788139.1547829474294@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788139.1547829474000.1133.1547829480015@Atlassian.JIRA>

Steven Hawkins created TEIID-5612:
-------------------------------------

             Summary: Switch to auto release
                 Key: TEIID-5612
                 URL: https://issues.jboss.org/browse/TEIID-5612
             Project: Teiid
          Issue Type: Enhancement
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins


Just like the thorntail parent, we should just auto release from staging http://central.maven.org/maven2/io/thorntail/parent/10/parent-10.pom

There are additional settings covered there as well, which would eliminate the need to specify them on the command line.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 18 12:37:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 18 Jan 2019 12:37:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833000000@Atlassian.JIRA>
References: <JIRA.12788149.1547833000000@Atlassian.JIRA>
	<JIRA.12788149.1547833000939@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833000000.1439.1547833020431@Atlassian.JIRA>

Steven Hawkins created TEIID-5613:
-------------------------------------

             Summary: upgrade to thorntail 2.3
                 Key: TEIID-5613
                 URL: https://issues.jboss.org/browse/TEIID-5613
             Project: Teiid
          Issue Type: Task
          Components: thorntail
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 13.0


Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 18 13:26:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 18 Jan 2019 13:26:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.1632.1547835960187@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684333#comment-13684333 ] 

Ramesh Reddy commented on TEIID-5613:
-------------------------------------

Did they update in a minor release to WF15?

> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 18 16:01:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Fri, 18 Jan 2019 16:01:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.2290.1547845260066@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684393#comment-13684393 ] 

Van Halbert commented on TEIID-5592:
------------------------------------

If we're going to split out the teiid-wildfly code and continue to support wildfly, should the teiid-quickstarts be moved to a similar repo:  wildfly-teiid-quickstarts (to follow the naming as the others).

> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 03:09:00 2019
From: issues at jboss.org (Tamar Meron (Jira))
Date: Mon, 21 Jan 2019 03:09:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5614) Teiid Spring Boot - Enable
 Spring Actuator and non OData requests
In-Reply-To: <JIRA.12788218.1548058116000@Atlassian.JIRA>
References: <JIRA.12788218.1548058116000@Atlassian.JIRA>
	<JIRA.12788218.1548058116030@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788218.1548058116000.3714.1548058140019@Atlassian.JIRA>

Tamar Meron created TEIID-5614:
----------------------------------

             Summary: Teiid Spring Boot - Enable Spring Actuator and non OData requests
                 Key: TEIID-5614
                 URL: https://issues.jboss.org/browse/TEIID-5614
             Project: Teiid
          Issue Type: Feature Request
            Reporter: Tamar Meron
            Assignee: Steven Hawkins


While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.

I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>null</code>
<message>
Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
</message>
</error>

I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.

I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
(didn't find any documentation for that "split" for OData version 4)
https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 

Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 09:05:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 09:05:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.7408.1548079503332@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685344#comment-13685344 ] 

Steven Hawkins commented on TEIID-5592:
---------------------------------------

That would just be a renaming, which yes I can go ahead and do.

> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 09:23:02 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 21 Jan 2019 09:23:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5614) Teiid Spring Boot - Enable
 Spring Actuator and non OData requests
In-Reply-To: <JIRA.12788218.1548058116000@Atlassian.JIRA>
References: <JIRA.12788218.1548058116000@Atlassian.JIRA>
	<JIRA.12788218.1548058116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788218.1548058116000.7517.1548080582398@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy reassigned TEIID-5614:
-----------------------------------

    Assignee: Ramesh Reddy  (was: Steven Hawkins)


> Teiid Spring Boot - Enable Spring Actuator and non OData requests
> -----------------------------------------------------------------
>
>                 Key: TEIID-5614
>                 URL: https://issues.jboss.org/browse/TEIID-5614
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Tamar Meron
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.
> I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
> Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>null</code>
> <message>
> Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
> </message>
> </error>
> I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.
> I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
> (didn't find any documentation for that "split" for OData version 4)
> https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 
> Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 09:24:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 09:24:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.7521.1548080640121@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685354#comment-13685354 ] 

Steven Hawkins commented on TEIID-5613:
---------------------------------------

No, skipped directly to 15 for 2.3:

https://github.com/thorntail/thorntail/blob/2.2.1.Final/build-parent/pom.xml
https://github.com/thorntail/thorntail/blob/2.3.0.Final/build-parent/pom.xml

This should mean though that 14 to 15 is a simple step.

> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 09:25:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 21 Jan 2019 09:25:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5614) Teiid Spring Boot - Enable
 Spring Actuator and non OData requests
In-Reply-To: <JIRA.12788218.1548058116000@Atlassian.JIRA>
References: <JIRA.12788218.1548058116000@Atlassian.JIRA>
	<JIRA.12788218.1548058116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788218.1548058116000.7529.1548080700831@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5614:
--------------------------------
    Description: 
While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.

I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":

{code}
<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>null</code>
  <message>
        Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
  </message>
</error>
{code}

I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.

I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
(didn't find any documentation for that "split" for OData version 4)
https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 

Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)

  was:
While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.

I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":

<error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>null</code>
<message>
Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
</message>
</error>

I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.

I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
(didn't find any documentation for that "split" for OData version 4)
https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 

Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)



> Teiid Spring Boot - Enable Spring Actuator and non OData requests
> -----------------------------------------------------------------
>
>                 Key: TEIID-5614
>                 URL: https://issues.jboss.org/browse/TEIID-5614
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Tamar Meron
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.
> I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
> Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":
> {code}
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>null</code>
>   <message>
>         Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
>   </message>
> </error>
> {code}
> I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.
> I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
> (didn't find any documentation for that "split" for OData version 4)
> https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 
> Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 10:02:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 21 Jan 2019 10:02:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.7951.1548082920703@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685389#comment-13685389 ] 

Ramesh Reddy commented on TEIID-5613:
-------------------------------------

WildFly has adjusted their rate of release of each major version to I believe every 6 months. We need to think of this release cadence and come up some strategy for Teiid.

> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 10:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 10:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.8157.1548084060303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685401#comment-13685401 ] 

Steven Hawkins commented on TEIID-5613:
---------------------------------------

We are at about 6 months for major releases.  In this case I didn't push further to WF 15 toward the end of the 12 cycle - Thorntail did.  Also from 14 to 15 was only 3 months for WildFly.


> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 10:23:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 21 Jan 2019 10:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.8170.1548084180362@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685404#comment-13685404 ] 

Ramesh Reddy commented on TEIID-5613:
-------------------------------------

Maybe I am misreading 6 months to 3 months, that means they have no dot releases at all

> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 11:07:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 11:07:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.8513.1548086820158@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685434#comment-13685434 ] 

Steven Hawkins commented on TEIID-5613:
---------------------------------------

The last WildFly .Y release was 10.1 in 2016.  They've only done a couple of ..Z minor releases, but otherwise a 3-4 month cadence for a major release after WildFly 11.



> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 13.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 15:43:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 15:43:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2957) MongoDB: Implement
 Compensating transactions
In-Reply-To: <JIRA.12540694.1400000365000@Atlassian.JIRA>
References: <JIRA.12540694.1400000365000@Atlassian.JIRA>
	<JIRA.12540694.1400000365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540694.1400000365000.9875.1548103380234@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-2957:
----------------------------------
    Git Pull Request: https://github.com/teiid/teiid/pull/1129


> MongoDB: Implement Compensating transactions
> --------------------------------------------
>
>                 Key: TEIID-2957
>                 URL: https://issues.jboss.org/browse/TEIID-2957
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.5
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Based on Narayana transaction manager, which is the TM that JBoss EAP TM based on one can build compensating transactions over MongoDB
> https://github.com/jbosstm/quickstart/blob/master/compensating-transactions/mongodb-simple/pom.xml
> https://plus.google.com/wm/1/events/cnbaif9aiiaarnjtd047nt1pksc
> Need to see the version number matches then need to buiild the necessary framework around mongodb translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 21 16:34:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 21 Jan 2019 16:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5594) Use generic rather than
 jboss javax dependencies for teiid core
In-Reply-To: <JIRA.12787122.1547214225000@Atlassian.JIRA>
References: <JIRA.12787122.1547214225000@Atlassian.JIRA>
	<JIRA.12787122.1547214225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787122.1547214225000.10011.1548106440162@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5594.
-----------------------------------
    Resolution: Done


Thanks Van.  Merged the PR with a minor change to use the non jboss slf4j - if that's needed we can switch back.

> Use generic rather than jboss javax dependencies for teiid core
> ---------------------------------------------------------------
>
>                 Key: TEIID-5594
>                 URL: https://issues.jboss.org/browse/TEIID-5594
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Minor
>             Fix For: 12.1
>
>
> The following dependencies are aligned to Wildfly, but that is unnecessary for embedded/springboot.  They should be replaced with more generic versions.
> {code}
> <dependency>
>                <groupId>org.jboss.spec.javax.ws.rs</groupId>
>                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.xml.ws</groupId>
>                <artifactId>jboss-jaxws-api_2.3_spec</artifactId>
>                <version>1.0.0.Final</version>
>            </dependency>
>            <dependency>
>                <groupId>org.jboss.spec.javax.servlet</groupId>
>                <artifactId>jboss-servlet-api_3.1_spec</artifactId>
>                <version>1.0.2.Final</version>
>            </dependency> 
>            <dependency>
>                <groupId>org.jboss.spec.javax.transaction</groupId>
>                <artifactId>jboss-transaction-api_1.2_spec</artifactId>
>                <version>1.1.1.Final</version>
>             </dependency>       
>             <dependency>
>                <groupId>org.jboss.spec.javax.xml.bind</groupId>
>                <artifactId>jboss-jaxb-api_2.3_spec</artifactId>
>                <version>1.0.1.Final</version>
>            </dependency>           
>             <dependency>
>                <groupId>org.slf4j</groupId>
>                <artifactId>slf4j-api</artifactId>
>                <version>1.7.22.jbossorg-1</version>
>             </dependency>
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 05:41:00 2019
From: issues at jboss.org (George Ushakov (Jira))
Date: Tue, 22 Jan 2019 05:41:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5615) Error when binding NULL to
 nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
In-Reply-To: <JIRA.12788547.1548153619000@Atlassian.JIRA>
References: <JIRA.12788547.1548153619000@Atlassian.JIRA>
	<JIRA.12788547.1548153619836@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788547.1548153619000.1097.1548153660093@Atlassian.JIRA>

George Ushakov created TEIID-5615:
-------------------------------------

             Summary: Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
                 Key: TEIID-5615
                 URL: https://issues.jboss.org/browse/TEIID-5615
             Project: Teiid
          Issue Type: Bug
          Components: ODBC
    Affects Versions: 11.2, 11.0
         Environment: All infrastructure is Dockerized on Windows 64bit (see below)

WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)

Teiid Engine 11.2.0

DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1)
PostgreSQL JDBC Driver=42.2.5

PDO Driver for PostgreSQL (from phpinfo())
PostgreSQL(libpq) Version: 9.6.10
Module version: 7.1.26
            Reporter: George Ushakov
            Assignee: Steven Hawkins


On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client.

PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bindvalue.php]
and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bindparam.php].

It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type.

Example PHP code


{code:php}
$dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>');
$stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)");
$stmt->bindValue(1, 1);
$stmt->bindValue(2, null, PDO::PARAM_NULL);
$stmt->execute();
{code}

Exception thrown is 

Caused by: java.lang.NegativeArraySizeException
        at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328)
        at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266)
        at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153)
        at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133)
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
        ... 15 more





--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 08:52:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 22 Jan 2019 08:52:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5615) Error when binding NULL to
 nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
In-Reply-To: <JIRA.12788547.1548153620000@Atlassian.JIRA>
References: <JIRA.12788547.1548153620000@Atlassian.JIRA>
	<JIRA.12788547.1548153620000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788547.1548153620000.3382.1548165123636@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5615 started by Steven Hawkins.
---------------------------------------------
> Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
> -----------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5615
>                 URL: https://issues.jboss.org/browse/TEIID-5615
>             Project: Teiid
>          Issue Type: Bug
>          Components: ODBC
>    Affects Versions: 11.0, 11.2
>         Environment: All infrastructure is Dockerized on Windows 64bit (see below)
> WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
> Teiid Engine 11.2.0
> DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1)
> PostgreSQL JDBC Driver=42.2.5
> PDO Driver for PostgreSQL (from phpinfo())
> PostgreSQL(libpq) Version: 9.6.10
> Module version: 7.1.26
>            Reporter: George Ushakov
>            Assignee: Steven Hawkins
>            Priority: Major
>
> On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client.
> PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bindvalue.php]
> and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bindparam.php].
> It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type.
> Example PHP code
> {code:php}
> $dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>');
> $stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)");
> $stmt->bindValue(1, 1);
> $stmt->bindValue(2, null, PDO::PARAM_NULL);
> $stmt->execute();
> {code}
> Exception thrown is 
> Caused by: java.lang.NegativeArraySizeException
>         at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328)
>         at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266)
>         at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153)
>         at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133)
>         at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
>         ... 15 more



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 09:04:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 22 Jan 2019 09:04:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5614) Teiid Spring Boot - Enable
 Spring Actuator and non OData requests
In-Reply-To: <JIRA.12788218.1548058116000@Atlassian.JIRA>
References: <JIRA.12788218.1548058116000@Atlassian.JIRA>
	<JIRA.12788218.1548058116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788218.1548058116000.3662.1548165840058@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685963#comment-13685963 ] 

Ramesh Reddy commented on TEIID-5614:
-------------------------------------

Looks like it is little quirky than I originally thought. In Actuator 1.x, the API at root context plus, Teiid used servlets to develop the OData API so that can code reuse from WildFly side. Here I suspect Actuator is using Spring MVC. I will able to redirect any servlet-based calls but when not a Spring MVC based requests.  Maybe I just need to leave it there for now, until we move up to Spring 2 and/or port OData stuff to Spring.

> Teiid Spring Boot - Enable Spring Actuator and non OData requests
> -----------------------------------------------------------------
>
>                 Key: TEIID-5614
>                 URL: https://issues.jboss.org/browse/TEIID-5614
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Tamar Meron
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.
> I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
> Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":
> {code}
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>null</code>
>   <message>
>         Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
>   </message>
> </error>
> {code}
> I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.
> I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
> (didn't find any documentation for that "split" for OData version 4)
> https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_Service_Resolution.html 
> Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 09:36:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 22 Jan 2019 09:36:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5616) Add build profile to
 disable building of wildfly
In-Reply-To: <JIRA.12788608.1548167724000@Atlassian.JIRA>
References: <JIRA.12788608.1548167724000@Atlassian.JIRA>
	<JIRA.12788608.1548167724370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788608.1548167724000.4106.1548167760473@Atlassian.JIRA>

Van Halbert created TEIID-5616:
----------------------------------

             Summary: Add build profile to disable building of wildfly
                 Key: TEIID-5616
                 URL: https://issues.jboss.org/browse/TEIID-5616
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
    Affects Versions: 12.x
            Reporter: Van Halbert
            Assignee: Steven Hawkins


Add build profile to disable the building of the wildfly related projects.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 09:36:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 22 Jan 2019 09:36:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5617) Insert command complete
 for pg/odbc is incorrect
In-Reply-To: <JIRA.12788609.1548167736000@Atlassian.JIRA>
References: <JIRA.12788609.1548167736000@Atlassian.JIRA>
	<JIRA.12788609.1548167736513@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788609.1548167736000.4112.1548167760633@Atlassian.JIRA>

Steven Hawkins created TEIID-5617:
-------------------------------------

             Summary: Insert command complete for pg/odbc is incorrect
                 Key: TEIID-5617
                 URL: https://issues.jboss.org/browse/TEIID-5617
             Project: Teiid
          Issue Type: Bug
          Components: ODBC
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1, 11.2.2, 12.0.1


The message format for insert command complete is INSERT oid rows, but we are sending INSERT rows.  Depending upon the client, such as using a newer JDBC driver, that will cause an exception on the client side.

{code}
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1967)
	at org.postgresql.core.v3.QueryExecutorImpl.interpretCommandStatus(QueryExecutorImpl.java:2528)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2134)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
	at org.postgresql.core.v3.ExtendedQueryExecutorImpl.execute(ExtendedQueryExecutorImpl.java:88)
	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
	at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:117)
	at org.teiid.transport.TestODBCSocketTransport.testPreparedNull(TestODBCSocketTransport.java:299)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
{code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 09:38:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 22 Jan 2019 09:38:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5616) Add build profile to
 disable building of wildfly
In-Reply-To: <JIRA.12788608.1548167724000@Atlassian.JIRA>
References: <JIRA.12788608.1548167724000@Atlassian.JIRA>
	<JIRA.12788608.1548167724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788608.1548167724000.4179.1548167881542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5616:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Add build profile to disable building of wildfly
> ------------------------------------------------
>
>                 Key: TEIID-5616
>                 URL: https://issues.jboss.org/browse/TEIID-5616
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> Add build profile to disable the building of the wildfly related projects.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 22 09:46:02 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Tue, 22 Jan 2019 09:46:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5618) clientHostName always
 reported as localhost via JDBC connection
In-Reply-To: <JIRA.12788613.1548168332000@Atlassian.JIRA>
References: <JIRA.12788613.1548168332000@Atlassian.JIRA>
	<JIRA.12788613.1548168332280@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788613.1548168332000.4433.1548168362590@Atlassian.JIRA>

Debbie Steigner created TEIID-5618:
--------------------------------------

             Summary: clientHostName always reported as localhost via JDBC connection
                 Key: TEIID-5618
                 URL: https://issues.jboss.org/browse/TEIID-5618
             Project: Teiid
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.12.16.6_4
            Reporter: Debbie Steigner
            Assignee: Steven Hawkins


VDB session information in the Management Console and logs shows localhost for Client Host Name with a JDBC connection.
Client Host Name: localhost
Client Hardware Address: 4CBB58502284
IP Address:	
Security Domain: teiid-security

In the server.log with org.teiid set to TRACE it displays below for session:

DEBUG [org.teiid.SECURITY] (New I/O worker #2) Logon successful, created session: sessionid=DW9hzUw5P1ob; userName=teiidUser at teiid-security; vdbName=deb_pg; vdbVersion=2; createdTime=Thu Jan 17 08:15:44 CST 2019; applicationName=JDBC; clientHostName=localhost; clientHardwareAddress=4CBB58502284; IPAddress=192.168.x.x; securityDomain=teiid-security; lastPingTime=Thu Jan 17 08:15:44 CST 2019



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:05:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:05:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5617) Insert command complete
 for pg/odbc is incorrect
In-Reply-To: <JIRA.12788609.1548167737000@Atlassian.JIRA>
References: <JIRA.12788609.1548167737000@Atlassian.JIRA>
	<JIRA.12788609.1548167737000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788609.1548167737000.11179.1548252300044@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5617.
-----------------------------------
    Resolution: Done


Updated the logic to add the 0 oid for the insert command complete.  At some point later we can investigate if it makes sense to determine a pseudo oid for returning generated keys.

> Insert command complete for pg/odbc is incorrect
> ------------------------------------------------
>
>                 Key: TEIID-5617
>                 URL: https://issues.jboss.org/browse/TEIID-5617
>             Project: Teiid
>          Issue Type: Bug
>          Components: ODBC
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> The message format for insert command complete is INSERT oid rows, but we are sending INSERT rows.  Depending upon the client, such as using a newer JDBC driver, that will cause an exception on the client side.
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> 	at java.lang.String.substring(String.java:1967)
> 	at org.postgresql.core.v3.QueryExecutorImpl.interpretCommandStatus(QueryExecutorImpl.java:2528)
> 	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2134)
> 	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
> 	at org.postgresql.core.v3.ExtendedQueryExecutorImpl.execute(ExtendedQueryExecutorImpl.java:88)
> 	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
> 	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
> 	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
> 	at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:117)
> 	at org.teiid.transport.TestODBCSocketTransport.testPreparedNull(TestODBCSocketTransport.java:299)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:19:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5619) Provide tables
 representing admin information
In-Reply-To: <JIRA.12788800.1548253136000@Atlassian.JIRA>
References: <JIRA.12788800.1548253136000@Atlassian.JIRA>
	<JIRA.12788800.1548253136766@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788800.1548253136000.11288.1548253140033@Atlassian.JIRA>

Steven Hawkins created TEIID-5619:
-------------------------------------

             Summary: Provide tables representing admin information
                 Key: TEIID-5619
                 URL: https://issues.jboss.org/browse/TEIID-5619
             Project: Teiid
          Issue Type: Quality Risk
          Components: Query Engine
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


Information provided over the admin api about sessions, requests, transactions, etc. should also be available via system tables.

Similarly many of the admin operations could be provided as system procedures - kill session, flush cache, etc.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:29:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:29:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253718000@Atlassian.JIRA>
References: <JIRA.12788805.1548253718000@Atlassian.JIRA>
	<JIRA.12788805.1548253718813@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253718000.11401.1548253740513@Atlassian.JIRA>

Steven Hawkins created TEIID-5620:
-------------------------------------

             Summary: Provide flattened jmx metrics
                 Key: TEIID-5620
                 URL: https://issues.jboss.org/browse/TEIID-5620
             Project: Teiid
          Issue Type: Quality Risk
          Components: Server
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins


Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.

We need to make sure that at least statistics are available on:
* number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
* amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk

Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.

It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:29:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:29:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.11410.1548253740747@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5620:
----------------------------------
    Fix Version/s: 12.1


> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:53:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.11605.1548255180078@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5555:
----------------------------------
    Fix Version/s:     (was: 11.2.2)


> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Critical
>             Fix For: 12.1
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:58:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:58:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5621) Provide rest access with
	SpringBoot
In-Reply-To: <JIRA.12788812.1548255467000@Atlassian.JIRA>
References: <JIRA.12788812.1548255467000@Atlassian.JIRA>
	<JIRA.12788812.1548255467870@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788812.1548255467000.11629.1548255480012@Atlassian.JIRA>

Steven Hawkins created TEIID-5621:
-------------------------------------

             Summary: Provide rest access with SpringBoot
                 Key: TEIID-5621
                 URL: https://issues.jboss.org/browse/TEIID-5621
             Project: Teiid
          Issue Type: Feature Request
          Components: Teiid Spring Boot
            Reporter: Steven Hawkins
            Assignee: Ramesh Reddy


The current rest access layer is based upon the generation of a war with deployment hooks in wildfly.  There should be a build-time or similar mechanism to expose rest with spring boot.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 09:59:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 09:59:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5615) Error when binding NULL to
 nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
In-Reply-To: <JIRA.12788547.1548153620000@Atlassian.JIRA>
References: <JIRA.12788547.1548153620000@Atlassian.JIRA>
	<JIRA.12788547.1548153620000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788547.1548153620000.11641.1548255540621@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5615.
-----------------------------------
    Fix Version/s: 12.1
                   11.2.2
                   12.0.1
       Resolution: Done


Your temporary fix is the correct one.  Null bindings are specified with a length of -1.

> Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
> -----------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5615
>                 URL: https://issues.jboss.org/browse/TEIID-5615
>             Project: Teiid
>          Issue Type: Bug
>          Components: ODBC
>    Affects Versions: 11.0, 11.2
>         Environment: All infrastructure is Dockerized on Windows 64bit (see below)
> WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
> Teiid Engine 11.2.0
> DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1)
> PostgreSQL JDBC Driver=42.2.5
> PDO Driver for PostgreSQL (from phpinfo())
> PostgreSQL(libpq) Version: 9.6.10
> Module version: 7.1.26
>            Reporter: George Ushakov
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client.
> PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bindvalue.php]
> and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bindparam.php].
> It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type.
> Example PHP code
> {code:php}
> $dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>');
> $stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)");
> $stmt->bindValue(1, 1);
> $stmt->bindValue(2, null, PDO::PARAM_NULL);
> $stmt->execute();
> {code}
> Exception thrown is 
> Caused by: java.lang.NegativeArraySizeException
>         at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328)
>         at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266)
>         at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153)
>         at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133)
>         at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
>         ... 15 more



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 10:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 10:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5622) Capture missing features
 from Teiid JDBC with the pg protocol
In-Reply-To: <JIRA.12788815.1548256831000@Atlassian.JIRA>
References: <JIRA.12788815.1548256831000@Atlassian.JIRA>
	<JIRA.12788815.1548256831270@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788815.1548256831000.11779.1548256860975@Atlassian.JIRA>

Steven Hawkins created TEIID-5622:
-------------------------------------

             Summary: Capture missing features from Teiid JDBC with the pg protocol
                 Key: TEIID-5622
                 URL: https://issues.jboss.org/browse/TEIID-5622
             Project: Teiid
          Issue Type: Quality Risk
          Components: JDBC Driver
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.x


We need to start spawning issues for missing features and known compatibility issues between Teiid JDBC and using the pg protocol - primarily with pg JDBC.

This includes:
* lob support - lo is not yet implemented in pg, just inlining TEIID-1163
* xa support - TEIID-4012
* query plan handling - TEIID-5527
* determine if reauthentication is supported
* domain type reporting - TEIID-4909
* typing differences in general - should there be a mode where we can report teiid type names?  that's likely not possible as many pg clients have builtin logic around the standard types
* multi-dimensional arrays
* like escape and other pg behavior that have workarounds in Teiid
* generated keys - we only return a 0 oid for inserts - what about upserts?




--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 10:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 10:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5622) Capture missing
 features/issues from Teiid JDBC with the pg protocol
In-Reply-To: <JIRA.12788815.1548256831000@Atlassian.JIRA>
References: <JIRA.12788815.1548256831000@Atlassian.JIRA>
	<JIRA.12788815.1548256831000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788815.1548256831000.11780.1548256860993@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5622:
----------------------------------
    Summary: Capture missing features/issues from Teiid JDBC with the pg protocol  (was: Capture missing features from Teiid JDBC with the pg protocol)


> Capture missing features/issues from Teiid JDBC with the pg protocol
> --------------------------------------------------------------------
>
>                 Key: TEIID-5622
>                 URL: https://issues.jboss.org/browse/TEIID-5622
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: JDBC Driver
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.x
>
>
> We need to start spawning issues for missing features and known compatibility issues between Teiid JDBC and using the pg protocol - primarily with pg JDBC.
> This includes:
> * lob support - lo is not yet implemented in pg, just inlining TEIID-1163
> * xa support - TEIID-4012
> * query plan handling - TEIID-5527
> * determine if reauthentication is supported
> * domain type reporting - TEIID-4909
> * typing differences in general - should there be a mode where we can report teiid type names?  that's likely not possible as many pg clients have builtin logic around the standard types
> * multi-dimensional arrays
> * like escape and other pg behavior that have workarounds in Teiid
> * generated keys - we only return a 0 oid for inserts - what about upserts?



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 10:35:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 10:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.11987.1548257700135@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686643#comment-13686643 ] 

Steven Hawkins commented on TEIID-5620:
---------------------------------------

We may need to also expose connection pool metrics - or see if there is dynamic adjustment possible.  It hasn't been discussed much about what the default sizing will be.  

Ideally there would be a non-blocking connection pool available - it sounds like there may be something coming out of the mp effort...

> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 10:47:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 10:47:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5623) Review open shift cpu and
 threading assumptions
In-Reply-To: <JIRA.12788824.1548258410000@Atlassian.JIRA>
References: <JIRA.12788824.1548258410000@Atlassian.JIRA>
	<JIRA.12788824.1548258410636@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788824.1548258410000.12046.1548258420103@Atlassian.JIRA>

Steven Hawkins created TEIID-5623:
-------------------------------------

             Summary: Review open shift cpu and threading assumptions
                 Key: TEIID-5623
                 URL: https://issues.jboss.org/browse/TEIID-5623
             Project: Teiid
          Issue Type: Quality Risk
          Components: Server
            Reporter: Steven Hawkins
            Assignee: Ramesh Reddy
             Fix For: 12.x


It also needs to be validated that we're correlating max active plans and connection pool sizings with the cpu limits set on our images.  Our default of 20 max active plans has been based upon performance primarily with dual / quad systems w / hyper threading.  I'm not sure how well this correlates to the virtual cpu limit.  Also we're using the available cpus setting to determine thread availability for sockets - so that may be unnecessarily overly constrained.  



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 11:16:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 11:16:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5618) clientHostName always
 reported as localhost via JDBC connection
In-Reply-To: <JIRA.12788613.1548168332000@Atlassian.JIRA>
References: <JIRA.12788613.1548168332000@Atlassian.JIRA>
	<JIRA.12788613.1548168332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788613.1548168332000.12282.1548260160071@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5618 started by Steven Hawkins.
---------------------------------------------
> clientHostName always reported as localhost via JDBC connection
> ---------------------------------------------------------------
>
>                 Key: TEIID-5618
>                 URL: https://issues.jboss.org/browse/TEIID-5618
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>
> VDB session information in the Management Console and logs shows localhost for Client Host Name with a JDBC connection.
> Client Host Name: localhost
> Client Hardware Address: 4CBB58502284
> IP Address:	
> Security Domain: teiid-security
> In the server.log with org.teiid set to TRACE it displays below for session:
> DEBUG [org.teiid.SECURITY] (New I/O worker #2) Logon successful, created session: sessionid=DW9hzUw5P1ob; userName=teiidUser at teiid-security; vdbName=deb_pg; vdbVersion=2; createdTime=Thu Jan 17 08:15:44 CST 2019; applicationName=JDBC; clientHostName=localhost; clientHardwareAddress=4CBB58502284; IPAddress=192.168.x.x; securityDomain=teiid-security; lastPingTime=Thu Jan 17 08:15:44 CST 2019



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 12:40:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 12:40:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5522) Avoid pushing join to
 datasource if DS cannot handle 1600+ columns
In-Reply-To: <JIRA.12776328.1540478055000@Atlassian.JIRA>
References: <JIRA.12776328.1540478055000@Atlassian.JIRA>
	<JIRA.12776328.1540478055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776328.1540478055000.12843.1548265200065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5522:
----------------------------------
    Fix Version/s: 12.1
                       (was: 12.x)


> Avoid pushing join to datasource if DS cannot handle 1600+ columns 
> -------------------------------------------------------------------
>
>                 Key: TEIID-5522
>                 URL: https://issues.jboss.org/browse/TEIID-5522
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors, Query Engine
>            Reporter: Norbert Funke
>            Priority: Major
>             Fix For: 12.1
>
>
> Problem: I am trying to create a wide view (~5000 columns), which works across data sources fine JDV. However, when I try to create the view with a join on 2+ table from data source, the optimizer pushes down the join to the source. The current source cannot handle more then ~1600 columns.
> Example: When trying to join Member_DX1 and Member_DX2 at client, JDV pushes the enter code herecombined join to postgres as one getting the too max column error.
> /* TABLE 1 */
> CREATE VIEW Member_DX1 (
>     MEMB_BID Integer
>      , DX130402000000 Integer
>      , DX180608000000 Integer
>      , DX20401070000 Integer
> .... /* 1000 more */
> as
> SELECT dx.memb_bid
> , case dx.EPI_1_DX4 when 130402000000 then 1 else 0 END as  DX130402000000                                              
> , case dx.EPI_1_DX4 when 180608000000 then 1 else 0 END as  DX180608000000                                              
> , case dx.EPI_1_DX4 when 20401070000 then 1 else 0 END as  DX20401070000
> ...
> FROM BDR.ENH_EPI_DETAIL dx 
> /* TABLE 2 */
> CREATE VIEW Member_DX2 (
>     MEMB_BID Integer
>      , DX200102010000 Integer
>      , DX90125000000 Integer
>      , DX160603070000 Integer
> ... /* 1000 more ...
> SELECT dx.memb_bid  /* FOREIGN TABLE */
> , case dx.EPI_1_DX4 when 200102010000 then 1 else 0 END as  DX200102010000                                              
> , case dx.EPI_1_DX4 when 90125000000 then 1 else 0 END as  DX90125000000                                                
> , case dx.EPI_1_DX4 when 160603070000 then 1 else 0 END as  DX160603070000      
> ...`enter code here`
> FROM BDR.ENH_EPI_DETAIL dx;
> then my query in (e.g. dBeaver) looks like this:
> SELECT * from Member_DX1 dx1
> join Member_DX2 dx2 
> on dx1.MEMB_BID = dx2.MEMB_BID



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 23 12:53:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 23 Jan 2019 12:53:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5504) Update pg layer for
	general fdw use
In-Reply-To: <JIRA.12773707.1539178006000@Atlassian.JIRA>
References: <JIRA.12773707.1539178006000@Atlassian.JIRA>
	<JIRA.12773707.1539178006000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773707.1539178006000.12928.1548265981056@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686722#comment-13686722 ] 

Steven Hawkins commented on TEIID-5504:
---------------------------------------

Another eventual goal would be to just reuse the pg metadata system.  That is via the fdw import all of the teiid constructs then any metadata query would be redirected to the pg instance.

We need to valid procedures, function, and other import at a minimum.  Beyond that if we want metadata visibility to apply then pg role functions need to be aware of the teiid role information.

> Update pg layer for general fdw use
> -----------------------------------
>
>                 Key: TEIID-5504
>                 URL: https://issues.jboss.org/browse/TEIID-5504
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: ODBC
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.x
>
>
> Building on TEIID-5498 we should allow general use of fdw access.  This is much broader in determining what function and type support is expected.  At the very least type casting needs to be aware of the pg type names as a literal like 'a' will be pushed as 'a'::text.
> At this time since joins and other higher level constructs are not pushed that still keeps the scope somewhat narrow.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 24 13:16:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 24 Jan 2019 13:16:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5624) Implement LO function
	support for pg/ODBC
In-Reply-To: <JIRA.12789143.1548353706000@Atlassian.JIRA>
References: <JIRA.12789143.1548353706000@Atlassian.JIRA>
	<JIRA.12789143.1548353706570@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789143.1548353706000.18875.1548353760123@Atlassian.JIRA>

Steven Hawkins created TEIID-5624:
-------------------------------------

             Summary: Implement LO function support for pg/ODBC
                 Key: TEIID-5624
                 URL: https://issues.jboss.org/browse/TEIID-5624
             Project: Teiid
          Issue Type: Feature Request
          Components: ODBC
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.x


The current logic maps lobs to bytea and text types and caps their length by default to 2MB.  We should add actual lob support using the LO functions.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 24 13:18:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 24 Jan 2019 13:18:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5618) clientHostName always
 reported as localhost via JDBC connection
In-Reply-To: <JIRA.12788613.1548168332000@Atlassian.JIRA>
References: <JIRA.12788613.1548168332000@Atlassian.JIRA>
	<JIRA.12788613.1548168332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788613.1548168332000.18884.1548353880101@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5618.
-----------------------------------
    Fix Version/s: 12.1
       Resolution: Done


Added async resolution on the client side.  By default we'll only attempt to get the host name for 100 milliseconds, then just use "unknown" - rather than "localhost".  ODBC for now will always use unknown.

> clientHostName always reported as localhost via JDBC connection
> ---------------------------------------------------------------
>
>                 Key: TEIID-5618
>                 URL: https://issues.jboss.org/browse/TEIID-5618
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> VDB session information in the Management Console and logs shows localhost for Client Host Name with a JDBC connection.
> Client Host Name: localhost
> Client Hardware Address: 4CBB58502284
> IP Address:	
> Security Domain: teiid-security
> In the server.log with org.teiid set to TRACE it displays below for session:
> DEBUG [org.teiid.SECURITY] (New I/O worker #2) Logon successful, created session: sessionid=DW9hzUw5P1ob; userName=teiidUser at teiid-security; vdbName=deb_pg; vdbVersion=2; createdTime=Thu Jan 17 08:15:44 CST 2019; applicationName=JDBC; clientHostName=localhost; clientHardwareAddress=4CBB58502284; IPAddress=192.168.x.x; securityDomain=teiid-security; lastPingTime=Thu Jan 17 08:15:44 CST 2019



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 24 13:23:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 24 Jan 2019 13:23:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2957) MongoDB: Implement
	transaction handling
In-Reply-To: <JIRA.12540694.1400000365000@Atlassian.JIRA>
References: <JIRA.12540694.1400000365000@Atlassian.JIRA>
	<JIRA.12540694.1400000365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540694.1400000365000.18906.1548354180245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-2957:
----------------------------------
    Description: With 4.x mongodb running in a replica set the latest client drivers expose methods that allow for the implementation of local transactions in jca.  (was: Based on Narayana transaction manager, which is the TM that JBoss EAP TM based on one can build compensating transactions over MongoDB

https://github.com/jbosstm/quickstart/blob/master/compensating-transactions/mongodb-simple/pom.xml

https://plus.google.com/wm/1/events/cnbaif9aiiaarnjtd047nt1pksc

Need to see the version number matches then need to buiild the necessary framework around mongodb translator

)
        Summary: MongoDB: Implement transaction handling  (was: MongoDB: Implement Compensating transactions)


> MongoDB: Implement transaction handling
> ---------------------------------------
>
>                 Key: TEIID-2957
>                 URL: https://issues.jboss.org/browse/TEIID-2957
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.5
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> With 4.x mongodb running in a replica set the latest client drivers expose methods that allow for the implementation of local transactions in jca.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 24 14:39:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 24 Jan 2019 14:39:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-2957) MongoDB: Implement
	transaction handling
In-Reply-To: <JIRA.12540694.1400000365000@Atlassian.JIRA>
References: <JIRA.12540694.1400000365000@Atlassian.JIRA>
	<JIRA.12540694.1400000365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540694.1400000365000.19112.1548358740254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-2957.
-----------------------------------
    Resolution: Done


Updated the docs, java docs for createDataSource, and release notes to cover adding a mongodb with local transaction support.

> MongoDB: Implement transaction handling
> ---------------------------------------
>
>                 Key: TEIID-2957
>                 URL: https://issues.jboss.org/browse/TEIID-2957
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Misc. Connectors
>    Affects Versions: 8.5
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> With 4.x mongodb running in a replica set the latest client drivers expose methods that allow for the implementation of local transactions in jca.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 24 15:34:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 24 Jan 2019 15:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5588) Please add support for
 earlyRequest feature which is for example used in the OpenUI5 library to
 enhance performance in single page apps
In-Reply-To: <JIRA.12786413.1546898013000@Atlassian.JIRA>
References: <JIRA.12786413.1546898013000@Atlassian.JIRA>
	<JIRA.12786413.1546898013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12786413.1546898013000.19221.1548362040082@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-5588:
-------------------------------------

      Component/s: OData
    Fix Version/s: Open To Community
         Assignee:     (was: Steven Hawkins)


> Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-5588
>                 URL: https://issues.jboss.org/browse/TEIID-5588
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>    Affects Versions: 11.2.1
>            Reporter: Christoph John
>            Priority: Optional
>             Fix For: Open To Community
>
>
> As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.
> Thomas Chadzelek, who I assume is a lead developer for the odata v4 model at SAP kindly provided the following information and offered his support in case further questions arise:
> The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.
> Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.
> For further questions you can contact him directly by joining the discussion at:
> https://github.com/SAP/openui5/issues/2288
> Thanks a lot. Let we know if I can support with testing.
> Best regards,
>  Christoph



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 09:48:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 25 Jan 2019 09:48:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.23411.1548427680021@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687674#comment-13687674 ] 

Steven Hawkins commented on TEIID-5620:
---------------------------------------

Other events that could be tracked as metrics for the purpose of alerting and dynamic adjustment:
* running 3 pass sorts - if there are no other memory / queuing issues it would imply that max active plans should smaller
* requests with full output buffers - indicates that the clients are initiating large queries then lagging the server output

> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 15:10:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 25 Jan 2019 15:10:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5625) Move Teiid Spring Boot to
 use Spring Boot 2.1.x
In-Reply-To: <JIRA.12789324.1548446957000@Atlassian.JIRA>
References: <JIRA.12789324.1548446957000@Atlassian.JIRA>
	<JIRA.12789324.1548446957698@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789324.1548446957000.24781.1548447000116@Atlassian.JIRA>

Ramesh Reddy created TEIID-5625:
-----------------------------------

             Summary: Move Teiid Spring Boot to use Spring Boot 2.1.x
                 Key: TEIID-5625
                 URL: https://issues.jboss.org/browse/TEIID-5625
             Project: Teiid
          Issue Type: Task
          Components: Teiid Spring Boot
            Reporter: Ramesh Reddy
            Assignee: Ramesh Reddy


Move current 1.5.x version of the spring boot Teiid to new Spring Boot version 2.1.2.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 15:22:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 25 Jan 2019 15:22:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5626) Support DDL based VDB
In-Reply-To: <JIRA.12789330.1548447684000@Atlassian.JIRA>
References: <JIRA.12789330.1548447684000@Atlassian.JIRA>
	<JIRA.12789330.1548447684980@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789330.1548447684000.24869.1548447720124@Atlassian.JIRA>

Ramesh Reddy created TEIID-5626:
-----------------------------------

             Summary: Support DDL based VDB
                 Key: TEIID-5626
                 URL: https://issues.jboss.org/browse/TEIID-5626
             Project: Teiid
          Issue Type: Enhancement
          Components: Teiid Spring Boot
            Reporter: Ramesh Reddy
            Assignee: Steven Hawkins


Support DDL based VDB for deployment in the Teiid Spring Boot. 

Consider moving the internal mechanics of building the dynamic VDB on API based schema object rather than Admin based objects. This could be a little messy to weed out.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 15:26:00 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Fri, 25 Jan 2019 15:26:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5627) Provide MongoDB source
	support
In-Reply-To: <JIRA.12789331.1548447951000@Atlassian.JIRA>
References: <JIRA.12789331.1548447951000@Atlassian.JIRA>
	<JIRA.12789331.1548447951662@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789331.1548447951000.24879.1548447960026@Atlassian.JIRA>

Ramesh Reddy created TEIID-5627:
-----------------------------------

             Summary: Provide MongoDB source support 
                 Key: TEIID-5627
                 URL: https://issues.jboss.org/browse/TEIID-5627
             Project: Teiid
          Issue Type: Feature Request
          Components: Teiid Spring Boot
            Reporter: Ramesh Reddy
            Assignee: Steven Hawkins


Provide support for MongoDB source in Teiid Spring Bott using MongoDB Spring Boot starter

{code}
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-mongodb</artifactId>
        </dependency>
{code}

and Teiid MongoDB translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 16:56:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 25 Jan 2019 16:56:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5628) Upgrade poi to 3.14
In-Reply-To: <JIRA.12789335.1548453348000@Atlassian.JIRA>
References: <JIRA.12789335.1548453348000@Atlassian.JIRA>
	<JIRA.12789335.1548453348401@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789335.1548453348000.25091.1548453360535@Atlassian.JIRA>

Steven Hawkins created TEIID-5628:
-------------------------------------

             Summary: Upgrade poi to 3.14
                 Key: TEIID-5628
                 URL: https://issues.jboss.org/browse/TEIID-5628
             Project: Teiid
          Issue Type: Quality Risk
          Components: Misc. Connectors
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


Performing the upgrade will remove the need for a dependency on dom4j, which overlaps with WildFly.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 16:57:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 25 Jan 2019 16:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5628) Upgrade poi to 3.13
In-Reply-To: <JIRA.12789335.1548453348000@Atlassian.JIRA>
References: <JIRA.12789335.1548453348000@Atlassian.JIRA>
	<JIRA.12789335.1548453348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789335.1548453348000.25092.1548453420031@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5628:
----------------------------------
    Summary: Upgrade poi to 3.13  (was: Upgrade poi to 3.14)


> Upgrade poi to 3.13
> -------------------
>
>                 Key: TEIID-5628
>                 URL: https://issues.jboss.org/browse/TEIID-5628
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Misc. Connectors
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Performing the upgrade will remove the need for a dependency on dom4j, which overlaps with WildFly.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Jan 25 17:05:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Fri, 25 Jan 2019 17:05:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5628) Upgrade poi to 3.13
In-Reply-To: <JIRA.12789335.1548453348000@Atlassian.JIRA>
References: <JIRA.12789335.1548453348000@Atlassian.JIRA>
	<JIRA.12789335.1548453348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789335.1548453348000.25099.1548453900120@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5628.
-----------------------------------
    Resolution: Done


Updated and removed dom4j.  Later versions pull in other dependencies unfortunately.  There is also an existing compile dependency on stax-api that wasn't reflected in the pom/module, so it appears to still not be needed by the module.

> Upgrade poi to 3.13
> -------------------
>
>                 Key: TEIID-5628
>                 URL: https://issues.jboss.org/browse/TEIID-5628
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Misc. Connectors
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Performing the upgrade will remove the need for a dependency on dom4j, which overlaps with WildFly.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Sun Jan 27 14:08:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Sun, 27 Jan 2019 14:08:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616030000@Atlassian.JIRA>
References: <JIRA.12789356.1548616030000@Atlassian.JIRA>
	<JIRA.12789356.1548616030771@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616030000.25628.1548616080138@Atlassian.JIRA>

Steven Hawkins created TEIID-5629:
-------------------------------------

             Summary: Upgrade to WildFly 15.0.1
                 Key: TEIID-5629
                 URL: https://issues.jboss.org/browse/TEIID-5629
             Project: Teiid
          Issue Type: Task
          Components: Server
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 

While we compile without issue - there are some errors running the integration tests having to do with some possibly new thread safety checks that wildfly is doing.  They seem to be cause an issue with the rest war deployment.

{code}
14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
{code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 08:20:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 08:20:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.30262.1548681600413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5620 started by Steven Hawkins.
---------------------------------------------
> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 08:20:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 08:20:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.30263.1548681600683@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5629 started by Steven Hawkins.
---------------------------------------------
> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 
> While we compile without issue - there are some errors running the integration tests having to do with some possibly new thread safety checks that wildfly is doing.  They seem to be cause an issue with the rest war deployment.
> {code}
> 14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 09:49:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 09:49:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.31929.1548686943785@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688222#comment-13688222 ] 

Steven Hawkins commented on TEIID-5629:
---------------------------------------

It looks like this should have affected wildfly 14 as well.  Last year checks were added such that the thread that creates the service must be the thread to install it.  That does not work with async loading of metadata.

> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 
> While we compile without issue - there are some errors running the integration tests having to do with some possibly new thread safety checks that wildfly is doing.  They seem to be cause an issue with the rest war deployment.
> {code}
> 14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 10:10:06 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 10:10:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.32115.1548688206311@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5629:
----------------------------------
    Description: The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail.   (was: The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 

While we compile without issue - there are some errors running the integration tests having to do with some possibly new thread safety checks that wildfly is doing.  They seem to be cause an issue with the rest war deployment.

{code}
14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
{code})


> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 10:12:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 10:12:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5630) Concurrency issue with
 wildfly service install
In-Reply-To: <JIRA.12789500.1548688276000@Atlassian.JIRA>
References: <JIRA.12789500.1548688276000@Atlassian.JIRA>
	<JIRA.12789500.1548688276597@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789500.1548688276000.32125.1548688320284@Atlassian.JIRA>

Steven Hawkins created TEIID-5630:
-------------------------------------

             Summary: Concurrency issue with wildfly service install
                 Key: TEIID-5630
                 URL: https://issues.jboss.org/browse/TEIID-5630
             Project: Teiid
          Issue Type: Bug
          Components: Server
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins


Checks were added such that the thread that creates the service must be the thread to install it. That does not work with async loading of metadata.

{code}
14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
{code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 10:12:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 10:12:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.32126.1548688320536@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688222#comment-13688222 ] 

Steven Hawkins edited comment on TEIID-5629 at 1/28/19 10:11 AM:
-----------------------------------------------------------------

It looks like TEIID-5629 should have affected wildfly 14 as well.


was (Author: shawkins):
It looks like this should have affected wildfly 14 as well.  Last year checks were added such that the thread that creates the service must be the thread to install it.  That does not work with async loading of metadata.

> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 10:13:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 10:13:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.32127.1548688380670@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688222#comment-13688222 ] 

Steven Hawkins edited comment on TEIID-5629 at 1/28/19 10:12 AM:
-----------------------------------------------------------------

It looks like TEIID-5630 should have affected wildfly 14 as well.


was (Author: shawkins):
It looks like TEIID-5629 should have affected wildfly 14 as well.

> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 10:21:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 10:21:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5630) Concurrency issue with
 wildfly service install
In-Reply-To: <JIRA.12789500.1548688277000@Atlassian.JIRA>
References: <JIRA.12789500.1548688277000@Atlassian.JIRA>
	<JIRA.12789500.1548688277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789500.1548688277000.32160.1548688860388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5630 started by Steven Hawkins.
---------------------------------------------
> Concurrency issue with wildfly service install
> ----------------------------------------------
>
>                 Key: TEIID-5630
>                 URL: https://issues.jboss.org/browse/TEIID-5630
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Checks were added such that the thread that creates the service must be the thread to install it. That does not work with async loading of metadata.
> {code}
> 14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 11:08:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 11:08:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5630) Concurrency issue with
 wildfly service install
In-Reply-To: <JIRA.12789500.1548688277000@Atlassian.JIRA>
References: <JIRA.12789500.1548688277000@Atlassian.JIRA>
	<JIRA.12789500.1548688277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789500.1548688277000.32860.1548691682077@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5630.
-----------------------------------
    Fix Version/s: 12.1
                   12.0.1
       Resolution: Done


Moved service creation and install to the same place.

> Concurrency issue with wildfly service install
> ----------------------------------------------
>
>                 Key: TEIID-5630
>                 URL: https://issues.jboss.org/browse/TEIID-5630
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 12.0.1
>
>
> Checks were added such that the thread that creates the service must be the thread to install it. That does not work with async loading of metadata.
> {code}
> 14:02:00,496 ERROR [org.teiid.RUNTIME] (Worker51)  TEIID30021 Uncaught exception processing work: java.util.ConcurrentModificationException: ServiceBuilder used by multiple threads
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 11:22:01 2019
From: issues at jboss.org (Johnathon Lee (Jira))
Date: Mon, 28 Jan 2019 11:22:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4476) Upgrade Cassandra Client
	library
In-Reply-To: <JIRA.12652070.1474925518000@Atlassian.JIRA>
References: <JIRA.12652070.1474925518000@Atlassian.JIRA>
	<JIRA.12652070.1474925518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652070.1474925518000.33015.1548692521335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated TEIID-4476:
---------------------------------
    Fix Version/s:     (was: 8.12.17.6_4)


> Upgrade Cassandra Client library
> --------------------------------
>
>                 Key: TEIID-4476
>                 URL: https://issues.jboss.org/browse/TEIID-4476
>             Project: Teiid
>          Issue Type: Task
>          Components: Misc. Connectors
>            Reporter: Ramesh Reddy
>            Assignee: Kylin Soong
>            Priority: Major
>             Fix For: 9.2
>
>
> Cassandra client version of the library is 2.1, this needs to be upgraded to the latest version.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4863) Run teiid embedded via
	Spring Boot
In-Reply-To: <JIRA.12687847.1492417853000@Atlassian.JIRA>
References: <JIRA.12687847.1492417853000@Atlassian.JIRA>
	<JIRA.12687847.1492417853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12687847.1492417853000.33372.1548694922774@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-4863:
----------------------------------
    Component/s: spring-boot


> Run teiid embedded via Spring Boot
> ----------------------------------
>
>                 Key: TEIID-4863
>                 URL: https://issues.jboss.org/browse/TEIID-4863
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot, Teiid Spring Boot
>    Affects Versions: 11.x
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: tsb-1.0.0
>
>
>  WildFly Swarm can use simple pojo to integrate framework, which compatible with  EmbeddedConfiguration, actually this is encouraged way.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5625) Move Teiid Spring Boot to
 use Spring Boot 2.1.x
In-Reply-To: <JIRA.12789324.1548446958000@Atlassian.JIRA>
References: <JIRA.12789324.1548446958000@Atlassian.JIRA>
	<JIRA.12789324.1548446958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789324.1548446958000.33375.1548694923787@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5625:
----------------------------------
    Component/s: spring-boot


> Move Teiid Spring Boot to use Spring Boot 2.1.x
> -----------------------------------------------
>
>                 Key: TEIID-5625
>                 URL: https://issues.jboss.org/browse/TEIID-5625
>             Project: Teiid
>          Issue Type: Task
>          Components: spring-boot, Teiid Spring Boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Move current 1.5.x version of the spring boot Teiid to new Spring Boot version 2.1.2.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:05 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5627) Provide MongoDB source
	support
In-Reply-To: <JIRA.12789331.1548447952000@Atlassian.JIRA>
References: <JIRA.12789331.1548447952000@Atlassian.JIRA>
	<JIRA.12789331.1548447952000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789331.1548447952000.33377.1548694925046@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5627:
----------------------------------
    Component/s: spring-boot


> Provide MongoDB source support 
> -------------------------------
>
>                 Key: TEIID-5627
>                 URL: https://issues.jboss.org/browse/TEIID-5627
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot, Teiid Spring Boot
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Provide support for MongoDB source in Teiid Spring Bott using MongoDB Spring Boot starter
> {code}
>         <dependency>
>             <groupId>org.springframework.boot</groupId>
>             <artifactId>spring-boot-starter-data-mongodb</artifactId>
>         </dependency>
> {code}
> and Teiid MongoDB translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:05 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5505) Support JAVA 11
In-Reply-To: <JIRA.12773811.1539197990000@Atlassian.JIRA>
References: <JIRA.12773811.1539197990000@Atlassian.JIRA>
	<JIRA.12773811.1539197990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773811.1539197990000.33379.1548694925810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5505:
----------------------------------
    Component/s: spring-boot


> Support JAVA 11
> ---------------
>
>                 Key: TEIID-5505
>                 URL: https://issues.jboss.org/browse/TEIID-5505
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Common, spring-boot, Teiid Spring Boot
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Support for JAVA 11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:06 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5285) Add high-level feature for
 redirection of updates
In-Reply-To: <JIRA.12739621.1521122286000@Atlassian.JIRA>
References: <JIRA.12739621.1521122286000@Atlassian.JIRA>
	<JIRA.12739621.1521122286000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12739621.1521122286000.33381.1548694926125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5285:
----------------------------------
    Component/s: spring-boot


> 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, spring-boot, Teiid Spring Boot
>            Reporter: Steven Hawkins
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.x
>
>         Attachments: redirection-vdb.xml
>
>
> 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.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:06 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5626) Support DDL based VDB
In-Reply-To: <JIRA.12789330.1548447685000@Atlassian.JIRA>
References: <JIRA.12789330.1548447685000@Atlassian.JIRA>
	<JIRA.12789330.1548447685000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789330.1548447685000.33383.1548694926934@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5626:
----------------------------------
    Component/s: spring-boot


> Support DDL based VDB
> ---------------------
>
>                 Key: TEIID-5626
>                 URL: https://issues.jboss.org/browse/TEIID-5626
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: spring-boot, Teiid Spring Boot
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Support DDL based VDB for deployment in the Teiid Spring Boot. 
> Consider moving the internal mechanics of building the dynamic VDB on API based schema object rather than Admin based objects. This could be a little messy to weed out.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:02:07 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:02:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5621) Provide rest access with
	SpringBoot
In-Reply-To: <JIRA.12788812.1548255468000@Atlassian.JIRA>
References: <JIRA.12788812.1548255468000@Atlassian.JIRA>
	<JIRA.12788812.1548255468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788812.1548255468000.33385.1548694927374@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5621:
----------------------------------
    Component/s: spring-boot


> Provide rest access with SpringBoot
> -----------------------------------
>
>                 Key: TEIID-5621
>                 URL: https://issues.jboss.org/browse/TEIID-5621
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot, Teiid Spring Boot
>            Reporter: Steven Hawkins
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> The current rest access layer is based upon the generation of a war with deployment hooks in wildfly.  There should be a build-time or similar mechanism to expose rest with spring boot.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:04 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5625) Move Teiid Spring Boot to
 use Spring Boot 2.1.x
In-Reply-To: <JIRA.12789324.1548446958000@Atlassian.JIRA>
References: <JIRA.12789324.1548446958000@Atlassian.JIRA>
	<JIRA.12789324.1548446958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789324.1548446958000.33392.1548694984405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5625:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Move Teiid Spring Boot to use Spring Boot 2.1.x
> -----------------------------------------------
>
>                 Key: TEIID-5625
>                 URL: https://issues.jboss.org/browse/TEIID-5625
>             Project: Teiid
>          Issue Type: Task
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Move current 1.5.x version of the spring boot Teiid to new Spring Boot version 2.1.2.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:05 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5626) Support DDL based VDB
In-Reply-To: <JIRA.12789330.1548447685000@Atlassian.JIRA>
References: <JIRA.12789330.1548447685000@Atlassian.JIRA>
	<JIRA.12789330.1548447685000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789330.1548447685000.33394.1548694985136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5626:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Support DDL based VDB
> ---------------------
>
>                 Key: TEIID-5626
>                 URL: https://issues.jboss.org/browse/TEIID-5626
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Support DDL based VDB for deployment in the Teiid Spring Boot. 
> Consider moving the internal mechanics of building the dynamic VDB on API based schema object rather than Admin based objects. This could be a little messy to weed out.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:05 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:05 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5627) Provide MongoDB source
	support
In-Reply-To: <JIRA.12789331.1548447952000@Atlassian.JIRA>
References: <JIRA.12789331.1548447952000@Atlassian.JIRA>
	<JIRA.12789331.1548447952000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789331.1548447952000.33396.1548694985848@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5627:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Provide MongoDB source support 
> -------------------------------
>
>                 Key: TEIID-5627
>                 URL: https://issues.jboss.org/browse/TEIID-5627
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Provide support for MongoDB source in Teiid Spring Bott using MongoDB Spring Boot starter
> {code}
>         <dependency>
>             <groupId>org.springframework.boot</groupId>
>             <artifactId>spring-boot-starter-data-mongodb</artifactId>
>         </dependency>
> {code}
> and Teiid MongoDB translator



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:06 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:06 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5621) Provide rest access with
	SpringBoot
In-Reply-To: <JIRA.12788812.1548255468000@Atlassian.JIRA>
References: <JIRA.12788812.1548255468000@Atlassian.JIRA>
	<JIRA.12788812.1548255468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788812.1548255468000.33398.1548694986814@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5621:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Provide rest access with SpringBoot
> -----------------------------------
>
>                 Key: TEIID-5621
>                 URL: https://issues.jboss.org/browse/TEIID-5621
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot
>            Reporter: Steven Hawkins
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> The current rest access layer is based upon the generation of a war with deployment hooks in wildfly.  There should be a build-time or similar mechanism to expose rest with spring boot.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:08 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5505) Support JAVA 11
In-Reply-To: <JIRA.12773811.1539197990000@Atlassian.JIRA>
References: <JIRA.12773811.1539197990000@Atlassian.JIRA>
	<JIRA.12773811.1539197990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773811.1539197990000.33403.1548694988640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5505:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Support JAVA 11
> ---------------
>
>                 Key: TEIID-5505
>                 URL: https://issues.jboss.org/browse/TEIID-5505
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Common, spring-boot
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Support for JAVA 11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:03:09 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:03:09 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5285) Add high-level feature for
 redirection of updates
In-Reply-To: <JIRA.12739621.1521122286000@Atlassian.JIRA>
References: <JIRA.12739621.1521122286000@Atlassian.JIRA>
	<JIRA.12739621.1521122286000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12739621.1521122286000.33405.1548694989153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5285:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> 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, spring-boot
>            Reporter: Steven Hawkins
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: 12.x
>
>         Attachments: redirection-vdb.xml
>
>
> 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.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:04:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:04:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4863) Run teiid embedded via
	Spring Boot
In-Reply-To: <JIRA.12687847.1492417853000@Atlassian.JIRA>
References: <JIRA.12687847.1492417853000@Atlassian.JIRA>
	<JIRA.12687847.1492417853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12687847.1492417853000.33407.1548695040767@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-4863:
----------------------------------
    Component/s:     (was: Teiid Spring Boot)


> Run teiid embedded via Spring Boot
> ----------------------------------
>
>                 Key: TEIID-4863
>                 URL: https://issues.jboss.org/browse/TEIID-4863
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: spring-boot
>    Affects Versions: 11.x
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>             Fix For: tsb-1.0.0
>
>
>  WildFly Swarm can use simple pojo to integrate framework, which compatible with  EmbeddedConfiguration, actually this is encouraged way.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 12:06:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 12:06:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.33429.1548695161655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5613:
----------------------------------
    Fix Version/s: teiid-tt-2.0.0
                   12.1
                       (was: 13.0)


> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, teiid-tt-2.0.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 13:39:02 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Mon, 28 Jan 2019 13:39:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5602) Move Teiid Spring Boot to
 Teiid 12 version
In-Reply-To: <JIRA.12787377.1547495159000@Atlassian.JIRA>
References: <JIRA.12787377.1547495159000@Atlassian.JIRA>
	<JIRA.12787377.1547495159000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787377.1547495159000.33792.1548700742541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5602:
--------------------------------
    Component/s: spring-boot


> Move Teiid Spring Boot to Teiid 12 version
> ------------------------------------------
>
>                 Key: TEIID-5602
>                 URL: https://issues.jboss.org/browse/TEIID-5602
>             Project: Teiid
>          Issue Type: Task
>          Components: spring-boot
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>            Priority: Major
>
> Move the current version supported by teiid spring boot to Teiid 12



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 14:09:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 14:09:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5629) Upgrade to WildFly 15.0.1
In-Reply-To: <JIRA.12789356.1548616031000@Atlassian.JIRA>
References: <JIRA.12789356.1548616031000@Atlassian.JIRA>
	<JIRA.12789356.1548616031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789356.1548616031000.33894.1548702543534@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5629.
-----------------------------------
    Resolution: Done


This updated a few of the common dependency versions - jdom was removed with TEIID-5628

The full test suite seems to run correctly.  Arquillian needed a new set of vm arguments that we handle via profile that was used to turn the tests off.

> Upgrade to WildFly 15.0.1
> -------------------------
>
>                 Key: TEIID-5629
>                 URL: https://issues.jboss.org/browse/TEIID-5629
>             Project: Teiid
>          Issue Type: Task
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The initial investigation makes it look like this upgrade is appropriate for a minor release.  The two benefits are java 11 support when running in wildfly and alignment with thorntail. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Jan 28 20:53:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Mon, 28 Jan 2019 20:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5613) upgrade to thorntail 2.3
In-Reply-To: <JIRA.12788149.1547833001000@Atlassian.JIRA>
References: <JIRA.12788149.1547833001000@Atlassian.JIRA>
	<JIRA.12788149.1547833001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788149.1547833001000.34976.1548726780314@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688420#comment-13688420 ] 

Steven Hawkins commented on TEIID-5613:
---------------------------------------

The code changes are in for master with some minor cleanup as well.  I'll see where appropriate doc updates should be made and add a forward looking cautionary statement about thorntail 4.x.

> upgrade to thorntail 2.3
> ------------------------
>
>                 Key: TEIID-5613
>                 URL: https://issues.jboss.org/browse/TEIID-5613
>             Project: Teiid
>          Issue Type: Task
>          Components: thorntail
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, tt-2.0.0
>
>
> Thorntail with THORN-2126 has intermediate versions, such as the 1.5.3 config-api, on wildfly 14 - but moved to WildFly 15 for the release.  I'll experiment a little if Teiid 12 is compatible enough to build Thorntail 2.3 support directly.  More than likely though we'll need to wait until Teiid 13 to sync back up.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 12:05:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 12:05:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5631) Issues with
	ThreadReuseExecutor
In-Reply-To: <JIRA.12789724.1548781471000@Atlassian.JIRA>
References: <JIRA.12789724.1548781471000@Atlassian.JIRA>
	<JIRA.12789724.1548781471415@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789724.1548781471000.43501.1548781500573@Atlassian.JIRA>

Steven Hawkins created TEIID-5631:
-------------------------------------

             Summary: Issues with ThreadReuseExecutor
                 Key: TEIID-5631
                 URL: https://issues.jboss.org/browse/TEIID-5631
             Project: Teiid
          Issue Type: Bug
          Components: Query Engine
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


In looking at flattening the metrics there are a couple of issues with the ThreadReuseExecutor:
1. The getStats method uses unsynchronized access to get the queue size.
2. The queue ordering prefers older work items to newer - even after repeated queuing.
3. Thread tracking could be more concurrent.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 13:13:01 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 29 Jan 2019 13:13:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5632) Support JAVA 11
In-Reply-To: <JIRA.12773811.1539197990000@Atlassian.JIRA>
References: <JIRA.12773811.1539197990000@Atlassian.JIRA>
	<JIRA.12773811.1539197990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773811.1539197990000.43894.1548785581130@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy moved TEIIDSB-10 to TEIID-5632:
--------------------------------------------

    Project: Teiid  (was: Teiid Spring Boot)
        Key: TEIID-5632  (was: TEIIDSB-10)


> Support JAVA 11
> ---------------
>
>                 Key: TEIID-5632
>                 URL: https://issues.jboss.org/browse/TEIID-5632
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Support for JAVA 11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 13:13:02 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Tue, 29 Jan 2019 13:13:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5632) Support JAVA 11
In-Reply-To: <JIRA.12773811.1539197990000@Atlassian.JIRA>
References: <JIRA.12773811.1539197990000@Atlassian.JIRA>
	<JIRA.12773811.1539197990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773811.1539197990000.43897.1548785582183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramesh Reddy updated TEIID-5632:
--------------------------------
    Fix Version/s: 12.0


> Support JAVA 11
> ---------------
>
>                 Key: TEIID-5632
>                 URL: https://issues.jboss.org/browse/TEIID-5632
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Support for JAVA 11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 13:24:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Tue, 29 Jan 2019 13:24:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5616) Add build profile to
 disable building of wildfly
In-Reply-To: <JIRA.12788608.1548167724000@Atlassian.JIRA>
References: <JIRA.12788608.1548167724000@Atlassian.JIRA>
	<JIRA.12788608.1548167724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788608.1548167724000.43920.1548786240110@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688852#comment-13688852 ] 

Van Halbert commented on TEIID-5616:
------------------------------------

Created new profile that only build the teiid core and excluded the wildfly sub projects,  use -P core-release  (otherwise, everything else should be the same)

> Add build profile to disable building of wildfly
> ------------------------------------------------
>
>                 Key: TEIID-5616
>                 URL: https://issues.jboss.org/browse/TEIID-5616
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> Add build profile to disable the building of the wildfly related projects.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 13:57:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 13:57:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5616) Add build profile to
 disable building of wildfly
In-Reply-To: <JIRA.12788608.1548167724000@Atlassian.JIRA>
References: <JIRA.12788608.1548167724000@Atlassian.JIRA>
	<JIRA.12788608.1548167724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788608.1548167724000.44077.1548788220841@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5616:
----------------------------------
    Fix Version/s: 12.1


> Add build profile to disable building of wildfly
> ------------------------------------------------
>
>                 Key: TEIID-5616
>                 URL: https://issues.jboss.org/browse/TEIID-5616
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Add build profile to disable the building of the wildfly related projects.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 14:00:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 14:00:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5632) Support JAVA 11
In-Reply-To: <JIRA.12773811.1539197990000@Atlassian.JIRA>
References: <JIRA.12773811.1539197990000@Atlassian.JIRA>
	<JIRA.12773811.1539197990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12773811.1539197990000.44083.1548788401466@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688863#comment-13688863 ] 

Steven Hawkins commented on TEIID-5632:
---------------------------------------

WildFly now works with the 15.0.1 upgrade.  The thorntail issue is targeted at 2.3.1, so it may necessitate a later respin of Teiid Thorntail. 

> Support JAVA 11
> ---------------
>
>                 Key: TEIID-5632
>                 URL: https://issues.jboss.org/browse/TEIID-5632
>             Project: Teiid
>          Issue Type: Feature Request
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.0
>
>
> Support for JAVA 11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 15:39:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 15:39:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5631) Issues with
	ThreadReuseExecutor
In-Reply-To: <JIRA.12789724.1548781471000@Atlassian.JIRA>
References: <JIRA.12789724.1548781471000@Atlassian.JIRA>
	<JIRA.12789724.1548781471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789724.1548781471000.44355.1548794340248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5631.
-----------------------------------
    Resolution: Done


Addressed the issues listed above.  Sampling now should be thread safe / non-blocking.

> Issues with ThreadReuseExecutor
> -------------------------------
>
>                 Key: TEIID-5631
>                 URL: https://issues.jboss.org/browse/TEIID-5631
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> In looking at flattening the metrics there are a couple of issues with the ThreadReuseExecutor:
> 1. The getStats method uses unsynchronized access to get the queue size.
> 2. The queue ordering prefers older work items to newer - even after repeated queuing.
> 3. Thread tracking could be more concurrent.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 15:51:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 15:51:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5616) Add build profile to
 disable building of wildfly
In-Reply-To: <JIRA.12788608.1548167724000@Atlassian.JIRA>
References: <JIRA.12788608.1548167724000@Atlassian.JIRA>
	<JIRA.12788608.1548167724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788608.1548167724000.44384.1548795060914@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5616.
-----------------------------------
    Resolution: Done


> Add build profile to disable building of wildfly
> ------------------------------------------------
>
>                 Key: TEIID-5616
>                 URL: https://issues.jboss.org/browse/TEIID-5616
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> Add build profile to disable the building of the wildfly related projects.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Jan 29 15:53:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Tue, 29 Jan 2019 15:53:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.44397.1548795180272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688906#comment-13688906 ] 

Steven Hawkins commented on TEIID-5620:
---------------------------------------

>From https://github.com/prometheus/jmx_exporter compositedata is fine, it just requires some additional keys in the export definition.  I'll test that out as well.  It likely means that we'll keep the existing admin/jmx bean structures and only add flattened values for the most important metrics.

> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 07:58:02 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 07:58:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853039000@Atlassian.JIRA>
References: <JIRA.12789852.1548853039000@Atlassian.JIRA>
	<JIRA.12789852.1548853039789@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853039000.50902.1548853082231@Atlassian.JIRA>

Van Halbert created TEIID-5633:
----------------------------------

             Summary: Configure to build on travis
                 Key: TEIID-5633
                 URL: https://issues.jboss.org/browse/TEIID-5633
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
    Affects Versions: 12.x
            Reporter: Van Halbert
            Assignee: Steven Hawkins


Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 07:58:02 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 07:58:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.50903.1548853082581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5633:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Configure to build on travis
> ----------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:14:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:14:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5634) Change pom so that samples
 are not built on release
In-Reply-To: <JIRA.12789858.1548854016000@Atlassian.JIRA>
References: <JIRA.12789858.1548854016000@Atlassian.JIRA>
	<JIRA.12789858.1548854016060@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789858.1548854016000.51919.1548854041338@Atlassian.JIRA>

Van Halbert created TEIID-5634:
----------------------------------

             Summary: Change pom so that samples are not built on release
                 Key: TEIID-5634
                 URL: https://issues.jboss.org/browse/TEIID-5634
             Project: Teiid
          Issue Type: Task
          Components: Build/Kits
    Affects Versions: 12.x
            Reporter: Van Halbert
            Assignee: Steven Hawkins


The pom needs to be changed so that the samples are not built as part of the release.   



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:17:07 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:17:07 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5634) Change pom so that samples
 are not built on release
In-Reply-To: <JIRA.12789858.1548854016000@Atlassian.JIRA>
References: <JIRA.12789858.1548854016000@Atlassian.JIRA>
	<JIRA.12789858.1548854016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789858.1548854016000.52213.1548854227879@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5634:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Change pom so that samples are not built on release
> ---------------------------------------------------
>
>                 Key: TEIID-5634
>                 URL: https://issues.jboss.org/browse/TEIID-5634
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> The pom needs to be changed so that the samples are not built as part of the release.   



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:17:08 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:17:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.52214.1548854228095@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689163#comment-13689163 ] 

Van Halbert commented on TEIID-5633:
------------------------------------

This does already have the .travis.yml file.  The settings on Travis just need to be enabled to turn  on building (which I don't have access).  Assigning to Steve.

> Configure to build on travis
> ----------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:17:08 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:17:08 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.52215.1548854228483@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5633:
----------------------------------

    Assignee: Steven Hawkins  (was: Van Halbert)


> Configure to build on travis
> ----------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:19:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 08:19:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.52290.1548854340799@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689165#comment-13689165 ] 

Steven Hawkins commented on TEIID-5633:
---------------------------------------

Can you be more specific?  What repo are you referring to?

> Configure to build on travis
> ----------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:23:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:23:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure
 teiid-spring-boot to build on travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.52329.1548854581346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert updated TEIID-5633:
-------------------------------
    Summary: Configure teiid-spring-boot to build on travis  (was: Configure to build on travis)


> Configure teiid-spring-boot to build on travis
> ----------------------------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:23:04 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:23:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure to build on
	travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.52342.1548854584823@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689170#comment-13689170 ] 

Van Halbert commented on TEIID-5633:
------------------------------------

That would help wouldn't it.   teiid-spring-boot.

> Configure to build on travis
> ----------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 08:25:02 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Wed, 30 Jan 2019 08:25:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5634) Change teiid-spring-boot
 pom so that samples are not built on release
In-Reply-To: <JIRA.12789858.1548854016000@Atlassian.JIRA>
References: <JIRA.12789858.1548854016000@Atlassian.JIRA>
	<JIRA.12789858.1548854016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789858.1548854016000.52351.1548854702121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert updated TEIID-5634:
-------------------------------
    Summary: Change teiid-spring-boot pom so that samples are not built on release  (was: Change pom so that samples are not built on release)


> Change teiid-spring-boot pom so that samples are not built on release
> ---------------------------------------------------------------------
>
>                 Key: TEIID-5634
>                 URL: https://issues.jboss.org/browse/TEIID-5634
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> The pom needs to be changed so that the samples are not built as part of the release.   



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 09:09:03 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 30 Jan 2019 09:09:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5634) Change teiid-spring-boot
 pom so that samples are not built on release
In-Reply-To: <JIRA.12789858.1548854016000@Atlassian.JIRA>
References: <JIRA.12789858.1548854016000@Atlassian.JIRA>
	<JIRA.12789858.1548854016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789858.1548854016000.53702.1548857343030@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689197#comment-13689197 ] 

Ramesh Reddy commented on TEIID-5634:
-------------------------------------

Any spring boot specific JIRAs now need to be on https://issues.jboss.org/projects/TEIIDSB/issues 

> Change teiid-spring-boot pom so that samples are not built on release
> ---------------------------------------------------------------------
>
>                 Key: TEIID-5634
>                 URL: https://issues.jboss.org/browse/TEIID-5634
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>
> The pom needs to be changed so that the samples are not built as part of the release.   



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 09:33:16 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 09:33:16 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.56380.1548858796759@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688906#comment-13688906 ] 

Steven Hawkins edited comment on TEIID-5620 at 1/30/19 9:27 AM:
----------------------------------------------------------------

>From https://github.com/prometheus/jmx_exporter and https://jolokia.org/reference/html/protocol.html#serialization-mxbean compositedata is fine, it just requires some additional keys in the export definition.  I'll test that out as well.  It likely means that we'll keep the existing admin/jmx bean structures and only add flattened values for the most important metrics.


was (Author: shawkins):
>From https://github.com/prometheus/jmx_exporter compositedata is fine, it just requires some additional keys in the export definition.  I'll test that out as well.  It likely means that we'll keep the existing admin/jmx bean structures and only add flattened values for the most important metrics.

> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 10:23:26 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 10:23:26 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5523) Allow for xsd schema
 association with vdb.xml
In-Reply-To: <JIRA.12776813.1540833741000@Atlassian.JIRA>
References: <JIRA.12776813.1540833741000@Atlassian.JIRA>
	<JIRA.12776813.1540833741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12776813.1540833741000.62110.1548861806729@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-5523:
----------------------------------
    Fix Version/s: 12.x
                       (was: 12.1)
         Priority: Minor  (was: Major)


> Allow for xsd schema association with vdb.xml
> ---------------------------------------------
>
>                 Key: TEIID-5523
>                 URL: https://issues.jboss.org/browse/TEIID-5523
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Build/Kits
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Minor
>             Fix For: 12.x
>
>
> Using Teiid Thorntail an exception is thrown at deployment when I attempt to associate an xsd with the vdb.xml file.  This would be helpful to assist with vdb editing.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 10:44:29 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 10:44:29 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4051) Swagger metadata includes
 internal java constructs
In-Reply-To: <JIRA.12609793.1457551979000@Atlassian.JIRA>
References: <JIRA.12609793.1457551979000@Atlassian.JIRA>
	<JIRA.12609793.1457551979000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609793.1457551979000.63625.1548863069566@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-4051 started by Steven Hawkins.
---------------------------------------------
> Swagger metadata includes internal java constructs
> --------------------------------------------------
>
>                 Key: TEIID-4051
>                 URL: https://issues.jboss.org/browse/TEIID-4051
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>    Affects Versions: 8.12.x
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> From IntegrationTestRestWarGeneration the swagger metadata includes definitions for Statement, ResultSet, StreamingOutput, etc.:
> ...
>   InputStream:
>     type: "object"
>   Statement:
>     type: "object"
>     properties:
>       queryTimeout:
>         type: "integer"
>         format: "int32"
>       closed:
>         type: "boolean"
>         default: false
>       resultSet:
>         $ref: "#/definitions/ResultSet"
> ...



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 10:44:30 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 10:44:30 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.63627.1548863070107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on TEIID-5555 started by Steven Hawkins.
---------------------------------------------
> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 10:44:49 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 10:44:49 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4051) Swagger metadata includes
 internal java constructs
In-Reply-To: <JIRA.12609793.1457551979000@Atlassian.JIRA>
References: <JIRA.12609793.1457551979000@Atlassian.JIRA>
	<JIRA.12609793.1457551979000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609793.1457551979000.63691.1548863089419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins reassigned TEIID-4051:
-------------------------------------

    Fix Version/s: 12.1
                       (was: 12.x)
         Assignee: Steven Hawkins  (was: Ramesh Reddy)


> Swagger metadata includes internal java constructs
> --------------------------------------------------
>
>                 Key: TEIID-4051
>                 URL: https://issues.jboss.org/browse/TEIID-4051
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>    Affects Versions: 8.12.x
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> From IntegrationTestRestWarGeneration the swagger metadata includes definitions for Statement, ResultSet, StreamingOutput, etc.:
> ...
>   InputStream:
>     type: "object"
>   Statement:
>     type: "object"
>     properties:
>       queryTimeout:
>         type: "integer"
>         format: "int32"
>       closed:
>         type: "boolean"
>         default: false
>       resultSet:
>         $ref: "#/definitions/ResultSet"
> ...



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 18:09:01 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Wed, 30 Jan 2019 18:09:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger)
 metadata document based on OData
In-Reply-To: <JIRA.12781634.1543533519000@Atlassian.JIRA>
References: <JIRA.12781634.1543533519000@Atlassian.JIRA>
	<JIRA.12781634.1543533519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781634.1543533519000.69213.1548889741733@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689484#comment-13689484 ] 

Steven Hawkins commented on TEIID-5555:
---------------------------------------

Linking to 3scale support for OpenApi 3.0 - which is still an open issue.  As of 3scale 2.4 only 1.2 and 2.0 are listed as supported.

> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
>                 Key: TEIID-5555
>                 URL: https://issues.jboss.org/browse/TEIID-5555
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: OData
>            Reporter: Ramesh Reddy
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 12.1
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Jan 30 18:46:04 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Wed, 30 Jan 2019 18:46:04 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5620) Provide flattened jmx
	metrics
In-Reply-To: <JIRA.12788805.1548253719000@Atlassian.JIRA>
References: <JIRA.12788805.1548253719000@Atlassian.JIRA>
	<JIRA.12788805.1548253719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12788805.1548253719000.69382.1548891964189@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689492#comment-13689492 ] 

Ramesh Reddy commented on TEIID-5620:
-------------------------------------

[~shawkins] When you mentioned about having the agent bond to have the metrics enabled in the image, I am already using the Java s2i image that has Prometheus and jolokia ports open, isn't those enough to see the metrics in hawtio/Prometheus consoles?

> Provide flattened jmx metrics
> -----------------------------
>
>                 Key: TEIID-5620
>                 URL: https://issues.jboss.org/browse/TEIID-5620
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types.  We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened.  Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 08:28:37 2019
From: issues at jboss.org (Ramesh Reddy (Jira))
Date: Thu, 31 Jan 2019 08:28:37 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5633) Configure
 teiid-spring-boot to build on travis
In-Reply-To: <JIRA.12789852.1548853040000@Atlassian.JIRA>
References: <JIRA.12789852.1548853040000@Atlassian.JIRA>
	<JIRA.12789852.1548853040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12789852.1548853040000.78891.1548941317201@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689195#comment-13689195 ] 

Ramesh Reddy commented on TEIID-5633:
-------------------------------------

spring boot already on travis :)

> Configure teiid-spring-boot to build on travis
> ----------------------------------------------
>
>                 Key: TEIID-5633
>                 URL: https://issues.jboss.org/browse/TEIID-5633
>             Project: Teiid
>          Issue Type: Task
>          Components: Build/Kits
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>            Priority: Major
>
> Add the travis.yml file to configure to build on travis



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 09:27:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 09:27:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5635) Remove references to Teiid
 Designer from the main docs
In-Reply-To: <JIRA.12790053.1548944782000@Atlassian.JIRA>
References: <JIRA.12790053.1548944782000@Atlassian.JIRA>
	<JIRA.12790053.1548944782868@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790053.1548944782000.80488.1548944820850@Atlassian.JIRA>

Steven Hawkins created TEIID-5635:
-------------------------------------

             Summary: Remove references to Teiid Designer from the main docs
                 Key: TEIID-5635
                 URL: https://issues.jboss.org/browse/TEIID-5635
             Project: Teiid
          Issue Type: Quality Risk
          Components: Documentation
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


Any Teiid Designer content in the docs should be replaced with the direct ddl functionality.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 09:57:02 2019
From: issues at jboss.org (Bram Gadeyne (Jira))
Date: Thu, 31 Jan 2019 09:57:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5636) Planning error. Could not
 find symbol disiz__1.DischargeTime
In-Reply-To: <JIRA.12790057.1548946605000@Atlassian.JIRA>
References: <JIRA.12790057.1548946605000@Atlassian.JIRA>
	<JIRA.12790057.1548946605362@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790057.1548946605000.80610.1548946622612@Atlassian.JIRA>

Bram Gadeyne created TEIID-5636:
-----------------------------------

             Summary: Planning error. Could not find symbol disiz__1.DischargeTime
                 Key: TEIID-5636
                 URL: https://issues.jboss.org/browse/TEIID-5636
             Project: Teiid
          Issue Type: Bug
    Affects Versions: 10.3.4
            Reporter: Bram Gadeyne
            Assignee: Steven Hawkins


Hi,

We're running into this exception. It happens when adding "LEFT OUTER JOIN izisprod.P_DischargeData". I unfortunitaly have no smaller example. We use this table all the time without any previous errors.

2019-01-31 15:32:36,438 ERROR [org.teiid.PROCESSOR] (Worker172_QueryProcessorQueue57002) JesgvCmnKfP5 TEIID30019 Unexpected exception for request JesgvCmnKfP5.187: org.teiid.core.TeiidRuntimeException: Planning error. Could not find symbol: disiz__1.DischargeTime
        at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:363)
        at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:129)
        at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:92)
        at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:98)
        at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:98)
        at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:87)
        at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:223)
        at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:135)
        at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111)
        at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160)
        at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142)
        at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:480)
        at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:350)
        at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
        at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
        at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
        at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
        at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 10:18:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 10:18:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5597) Retire teiid.jboss.org
In-Reply-To: <JIRA.12787364.1547486183000@Atlassian.JIRA>
References: <JIRA.12787364.1547486183000@Atlassian.JIRA>
	<JIRA.12787364.1547486183000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787364.1547486183000.80750.1548947880574@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689794#comment-13689794 ] 

Steven Hawkins commented on TEIID-5597:
---------------------------------------

There are few doc links that still point to www.jboss.org/teiid as well.

> Retire teiid.jboss.org
> ----------------------
>
>                 Key: TEIID-5597
>                 URL: https://issues.jboss.org/browse/TEIID-5597
>             Project: Teiid
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The legacy site will have been unmaintained since approximately a 4/2018.  We can leave archive information, such as doc and old download links in place - but all other content should be removed or ported to teiid.io.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 10:47:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 10:47:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5637) remove object translator
	documentation
In-Reply-To: <JIRA.12790070.1548949587000@Atlassian.JIRA>
References: <JIRA.12790070.1548949587000@Atlassian.JIRA>
	<JIRA.12790070.1548949587481@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790070.1548949587000.81014.1548949622892@Atlassian.JIRA>

Steven Hawkins created TEIID-5637:
-------------------------------------

             Summary: remove object translator documentation
                 Key: TEIID-5637
                 URL: https://issues.jboss.org/browse/TEIID-5637
             Project: Teiid
          Issue Type: Quality Risk
          Components: Documentation
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins


The map-cache translator was removed for Teiid 10 as it was superseded by other infinispan support - and was never fully realized as a general access mechanism to other caching systems.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 11:06:02 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 11:06:02 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5637) remove object translator
	documentation
In-Reply-To: <JIRA.12790070.1548949587000@Atlassian.JIRA>
References: <JIRA.12790070.1548949587000@Atlassian.JIRA>
	<JIRA.12790070.1548949587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790070.1548949587000.81189.1548950762070@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5637.
-----------------------------------
    Fix Version/s: 12.1
                   11.2.2
                   12.0.1
       Resolution: Done


Removed the page from the reference doc.

> remove object translator documentation
> --------------------------------------
>
>                 Key: TEIID-5637
>                 URL: https://issues.jboss.org/browse/TEIID-5637
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Documentation
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1, 11.2.2, 12.0.1
>
>
> The map-cache translator was removed for Teiid 10 as it was superseded by other infinispan support - and was never fully realized as a general access mechanism to other caching systems.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 11:48:03 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 11:48:03 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5635) Remove references to Teiid
 Designer from the main docs
In-Reply-To: <JIRA.12790053.1548944783000@Atlassian.JIRA>
References: <JIRA.12790053.1548944783000@Atlassian.JIRA>
	<JIRA.12790053.1548944783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790053.1548944783000.81462.1548953283315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-5635.
-----------------------------------
    Resolution: Done


The only references left refer to deprecations.

> Remove references to Teiid Designer from the main docs
> ------------------------------------------------------
>
>                 Key: TEIID-5635
>                 URL: https://issues.jboss.org/browse/TEIID-5635
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Documentation
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> Any Teiid Designer content in the docs should be replaced with the direct ddl functionality.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 12:07:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 12:07:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5636) Planning error. Could not
 find symbol disiz__1.DischargeTime
In-Reply-To: <JIRA.12790057.1548946605000@Atlassian.JIRA>
References: <JIRA.12790057.1548946605000@Atlassian.JIRA>
	<JIRA.12790057.1548946605000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790057.1548946605000.81555.1548954420351@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689866#comment-13689866 ] 

Steven Hawkins commented on TEIID-5636:
---------------------------------------

> I unfortunitaly have no smaller example. We use this table all the time without any previous errors.

It shouldn't be related to the individual table.  Are you able to provide the entire query structure?

Are you able to reproduce this on a later version, such as 11.2.1?

> Planning error. Could not find symbol disiz__1.DischargeTime
> ------------------------------------------------------------
>
>                 Key: TEIID-5636
>                 URL: https://issues.jboss.org/browse/TEIID-5636
>             Project: Teiid
>          Issue Type: Bug
>    Affects Versions: 10.3.4
>            Reporter: Bram Gadeyne
>            Assignee: Steven Hawkins
>            Priority: Critical
>
> Hi,
> We're running into this exception. It happens when adding "LEFT OUTER JOIN izisprod.P_DischargeData". I unfortunitaly have no smaller example. We use this table all the time without any previous errors.
> 2019-01-31 15:32:36,438 ERROR [org.teiid.PROCESSOR] (Worker172_QueryProcessorQueue57002) JesgvCmnKfP5 TEIID30019 Unexpected exception for request JesgvCmnKfP5.187: org.teiid.core.TeiidRuntimeException: Planning error. Could not find symbol: disiz__1.DischargeTime
>         at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:363)
>         at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:129)
>         at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:92)
>         at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:98)
>         at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:98)
>         at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:87)
>         at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:223)
>         at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:135)
>         at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111)
>         at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160)
>         at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142)
>         at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:480)
>         at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:350)
>         at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
>         at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
>         at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
>         at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
>         at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 12:34:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 31 Jan 2019 12:34:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.81676.1548956040485@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5592:
----------------------------------

    Assignee: Steven Hawkins  (was: Van Halbert)


> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 12:56:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 12:56:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.81709.1548957360285@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689883#comment-13689883 ] 

Steven Hawkins commented on TEIID-5592:
---------------------------------------

[~rhn-engineering-vhalbert] any thoughts on this how easy or worth it is to update?  That would remove references to JDV and use Teiid 12.0?

> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 13:41:00 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 31 Jan 2019 13:41:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.81798.1548960060342@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689892#comment-13689892 ] 

Van Halbert commented on TEIID-5592:
------------------------------------

To remove references, should be easy to do.    However, to test all the quickstarts against teiid 12 will take some time.

And your wording is, is it worth it.  What is the alternative, other than not doing?

> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 15:32:00 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Thu, 31 Jan 2019 15:32:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5638) Add Swagger UI location
 for auto-generated REST war in documentation
In-Reply-To: <JIRA.12790094.1548966708000@Atlassian.JIRA>
References: <JIRA.12790094.1548966708000@Atlassian.JIRA>
	<JIRA.12790094.1548966708132@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790094.1548966708000.82138.1548966720024@Atlassian.JIRA>

Debbie Steigner created TEIID-5638:
--------------------------------------

             Summary: Add Swagger UI location for auto-generated REST war in documentation
                 Key: TEIID-5638
                 URL: https://issues.jboss.org/browse/TEIID-5638
             Project: Teiid
          Issue Type: Feature Request
          Components: Documentation
            Reporter: Debbie Steigner
            Assignee: Steven Hawkins


When using the Designer generated REST war, Swagger UI is at http://localhost:8080/VDB but if using the auto-generated war file it is at http://localhost:8080/VDB_1/api.  Can this be noted in the documentation?



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 16:10:00 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Thu, 31 Jan 2019 16:10:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5639) Auto-generated REST war
 creates different context than Designer Generated REST war
In-Reply-To: <JIRA.12790098.1548968942000@Atlassian.JIRA>
References: <JIRA.12790098.1548968942000@Atlassian.JIRA>
	<JIRA.12790098.1548968942482@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790098.1548968942000.82201.1548969000766@Atlassian.JIRA>

Debbie Steigner created TEIID-5639:
--------------------------------------

             Summary: Auto-generated REST war creates different context than Designer Generated REST war
                 Key: TEIID-5639
                 URL: https://issues.jboss.org/browse/TEIID-5639
             Project: Teiid
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.12.16.6_4
            Reporter: Debbie Steigner
            Assignee: Steven Hawkins
         Attachments: AutoGenSwaggar.png, DesignerGenSwagger.png

Have a REST procedure with 3 optional parameters and have the REST:URI set to testget&inA&inB&inC, the Designer Generated War takes the REST:URI of testget&inA&inB&inC and drops the params, so you see in the Swagger UI the operation is just /AAA/testget, so the Request URL is http://localhost:8080/WW/AAA/testget?inA=abc&inC=def but the auto-generated war file doesn't drop the params from the REST:URI and it shows as /AAA/testget&inA&inB&inC so the actual Request URL would be http://localhost:8080/WW_1/AAA/testget&inA&inB&inC?inA=abc&inC=def.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 16:10:01 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Thu, 31 Jan 2019 16:10:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5639) Auto-generated REST war
 creates different context than Designer Generated REST war
In-Reply-To: <JIRA.12790098.1548968942000@Atlassian.JIRA>
References: <JIRA.12790098.1548968942000@Atlassian.JIRA>
	<JIRA.12790098.1548968942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790098.1548968942000.82202.1548969001067@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Debbie Steigner updated TEIID-5639:
-----------------------------------
    Attachment: AutoGenSwaggar.png


> Auto-generated REST war creates different context than Designer Generated REST war
> ----------------------------------------------------------------------------------
>
>                 Key: TEIID-5639
>                 URL: https://issues.jboss.org/browse/TEIID-5639
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AutoGenSwaggar.png, DesignerGenSwagger.png
>
>
> Have a REST procedure with 3 optional parameters and have the REST:URI set to testget&inA&inB&inC, the Designer Generated War takes the REST:URI of testget&inA&inB&inC and drops the params, so you see in the Swagger UI the operation is just /AAA/testget, so the Request URL is http://localhost:8080/WW/AAA/testget?inA=abc&inC=def but the auto-generated war file doesn't drop the params from the REST:URI and it shows as /AAA/testget&inA&inB&inC so the actual Request URL would be http://localhost:8080/WW_1/AAA/testget&inA&inB&inC?inA=abc&inC=def.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 16:10:01 2019
From: issues at jboss.org (Van Halbert (Jira))
Date: Thu, 31 Jan 2019 16:10:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.82203.1548969001372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Van Halbert reassigned TEIID-5592:
----------------------------------

    Assignee: Van Halbert  (was: Steven Hawkins)


> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 16:10:01 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Thu, 31 Jan 2019 16:10:01 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5639) Auto-generated REST war
 creates different context than Designer Generated REST war
In-Reply-To: <JIRA.12790098.1548968942000@Atlassian.JIRA>
References: <JIRA.12790098.1548968942000@Atlassian.JIRA>
	<JIRA.12790098.1548968942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790098.1548968942000.82205.1548969001938@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Debbie Steigner updated TEIID-5639:
-----------------------------------
    Attachment: DesignerGenSwagger.png


> Auto-generated REST war creates different context than Designer Generated REST war
> ----------------------------------------------------------------------------------
>
>                 Key: TEIID-5639
>                 URL: https://issues.jboss.org/browse/TEIID-5639
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AutoGenSwaggar.png, DesignerGenSwagger.png
>
>
> Have a REST procedure with 3 optional parameters and have the REST:URI set to testget&inA&inB&inC, the Designer Generated War takes the REST:URI of testget&inA&inB&inC and drops the params, so you see in the Swagger UI the operation is just /AAA/testget, so the Request URL is http://localhost:8080/WW/AAA/testget?inA=abc&inC=def but the auto-generated war file doesn't drop the params from the REST:URI and it shows as /AAA/testget&inA&inB&inC so the actual Request URL would be http://localhost:8080/WW_1/AAA/testget&inA&inB&inC?inA=abc&inC=def.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 16:11:00 2019
From: issues at jboss.org (Debbie Steigner (Jira))
Date: Thu, 31 Jan 2019 16:11:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5639) Auto-generated REST war
 creates different context than Designer Generated REST war
In-Reply-To: <JIRA.12790098.1548968942000@Atlassian.JIRA>
References: <JIRA.12790098.1548968942000@Atlassian.JIRA>
	<JIRA.12790098.1548968942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790098.1548968942000.82206.1548969060957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/TEIID-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Debbie Steigner updated TEIID-5639:
-----------------------------------
    Attachment: WW-vdb.xml


> Auto-generated REST war creates different context than Designer Generated REST war
> ----------------------------------------------------------------------------------
>
>                 Key: TEIID-5639
>                 URL: https://issues.jboss.org/browse/TEIID-5639
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AutoGenSwaggar.png, DesignerGenSwagger.png, WW-vdb.xml
>
>
> Have a REST procedure with 3 optional parameters and have the REST:URI set to testget&inA&inB&inC, the Designer Generated War takes the REST:URI of testget&inA&inB&inC and drops the params, so you see in the Swagger UI the operation is just /AAA/testget, so the Request URL is http://localhost:8080/WW/AAA/testget?inA=abc&inC=def but the auto-generated war file doesn't drop the params from the REST:URI and it shows as /AAA/testget&inA&inB&inC so the actual Request URL would be http://localhost:8080/WW_1/AAA/testget&inA&inB&inC?inA=abc&inC=def.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 17:09:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 17:09:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5640) Don't provide access to
 system schema over odata
In-Reply-To: <JIRA.12790103.1548972536000@Atlassian.JIRA>
References: <JIRA.12790103.1548972536000@Atlassian.JIRA>
	<JIRA.12790103.1548972536851@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790103.1548972536000.82363.1548972540467@Atlassian.JIRA>

Steven Hawkins created TEIID-5640:
-------------------------------------

             Summary: Don't provide access to system schema over odata
                 Key: TEIID-5640
                 URL: https://issues.jboss.org/browse/TEIID-5640
             Project: Teiid
          Issue Type: Quality Risk
          Components: OData
            Reporter: Steven Hawkins
            Assignee: Steven Hawkins
             Fix For: 12.1


We now create all of the edm metadata at once - including for system schema - but we should not allow that by default.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 17:39:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 17:39:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5592) Update or deprecate
	teiid-quickstarts
In-Reply-To: <JIRA.12787031.1547138714000@Atlassian.JIRA>
References: <JIRA.12787031.1547138714000@Atlassian.JIRA>
	<JIRA.12787031.1547138714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12787031.1547138714000.82399.1548974340331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689938#comment-13689938 ] 

Steven Hawkins commented on TEIID-5592:
---------------------------------------

The alternative is to deprecate - on the website and in the repo make it clear that it was written for older Teiids and JDV.

> Update or deprecate teiid-quickstarts
> -------------------------------------
>
>                 Key: TEIID-5592
>                 URL: https://issues.jboss.org/browse/TEIID-5592
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Quick Starts
>            Reporter: Steven Hawkins
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11.  However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 18:12:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 18:12:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-4051) Swagger metadata includes
 internal java constructs
In-Reply-To: <JIRA.12609793.1457551979000@Atlassian.JIRA>
References: <JIRA.12609793.1457551979000@Atlassian.JIRA>
	<JIRA.12609793.1457551979000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609793.1457551979000.82498.1548976320303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689939#comment-13689939 ] 

Steven Hawkins commented on TEIID-4051:
---------------------------------------

A related issue - https://github.com/swagger-api/swagger-codegen/issues/4831

It looks like the swagger utilities still don't understand StreamingOutput

> Swagger metadata includes internal java constructs
> --------------------------------------------------
>
>                 Key: TEIID-4051
>                 URL: https://issues.jboss.org/browse/TEIID-4051
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Server
>    Affects Versions: 8.12.x
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>             Fix For: 12.1
>
>
> From IntegrationTestRestWarGeneration the swagger metadata includes definitions for Statement, ResultSet, StreamingOutput, etc.:
> ...
>   InputStream:
>     type: "object"
>   Statement:
>     type: "object"
>     properties:
>       queryTimeout:
>         type: "integer"
>         format: "int32"
>       closed:
>         type: "boolean"
>         default: false
>       resultSet:
>         $ref: "#/definitions/ResultSet"
> ...



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Jan 31 18:35:00 2019
From: issues at jboss.org (Steven Hawkins (Jira))
Date: Thu, 31 Jan 2019 18:35:00 -0500 (EST)
Subject: [teiid-issues] [JBoss JIRA] (TEIID-5639) Auto-generated REST war
 creates different context than Designer Generated REST war
In-Reply-To: <JIRA.12790098.1548968942000@Atlassian.JIRA>
References: <JIRA.12790098.1548968942000@Atlassian.JIRA>
	<JIRA.12790098.1548968942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12790098.1548968942000.82559.1548977700265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/TEIID-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689945#comment-13689945 ] 

Steven Hawkins commented on TEIID-5639:
---------------------------------------

[~dsteigne] I'd say this is an issue with Designer.  The Teiid side is documented as expecting uri parameters in curly braces - http://teiid.github.io/teiid-documents/master/content/reference/REST_Service_Through_VDB.html  - which matches the jax rs specification.

> Auto-generated REST war creates different context than Designer Generated REST war
> ----------------------------------------------------------------------------------
>
>                 Key: TEIID-5639
>                 URL: https://issues.jboss.org/browse/TEIID-5639
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.12.16.6_4
>            Reporter: Debbie Steigner
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: AutoGenSwaggar.png, DesignerGenSwagger.png, WW-vdb.xml
>
>
> Have a REST procedure with 3 optional parameters and have the REST:URI set to testget&inA&inB&inC, the Designer Generated War takes the REST:URI of testget&inA&inB&inC and drops the params, so you see in the Swagger UI the operation is just /AAA/testget, so the Request URL is http://localhost:8080/WW/AAA/testget?inA=abc&inC=def but the auto-generated war file doesn't drop the params from the REST:URI and it shows as /AAA/testget&inA&inB&inC so the actual Request URL would be http://localhost:8080/WW_1/AAA/testget&inA&inB&inC?inA=abc&inC=def.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)