[JBoss JIRA] (TEIID-5343) Enable absolute URI on context definition of EntitySets when using ODATA
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5343?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5343:
-------------------------------------
Great, thanks for the feedback.
> Enable absolute URI on context definition of EntitySets when using ODATA
> ------------------------------------------------------------------------
>
> Key: TEIID-5343
> URL: https://issues.jboss.org/browse/TEIID-5343
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Affects Versions: 10.2.1
> Reporter: Rafael Sampaio
> Assignee: Ramesh Reddy
> Fix For: 11.1
>
>
> Hi all you TEIID guys.
> As reported on [OLINGO-1025|https://issues.apache.org/jira/browse/OLINGO-1025], integrating to MS OData consumers (ie. PowerBI/PowerQuery) gives the "should be an absolute Uri" error.
> The proposed solution in the JIRA is implementing a Processor for any given EntityType. Browsing through the code i see TEIID uses the ServiceHandler approach, instead of processor and it also has a Custom JSON Odata Serializer.
> I see that the Default JSON serializer, when serializing entity collections uses the ContextURL to generate the context metadata for the EntityCollection, but by default it does not contain the service root, since it comes from static DataRequest.buildEntitySetContextURL(olingo) method.
> Would be nice if we could choose this behavior through a init param in the odata deployment.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-5372) Enhance docker support
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5372:
---------------------------------------
> Great, I could work on a page describing different deployment models some time next week and put it under Teiid 4 Ways.
I took a pass at changing that page to Teiid Runtimes and reduce the number of mentions of embedded. We could also use the term Application Runtimes to fully align with RHOAR messaging.
At most we would then describe each of standalone, docker, and openshift for each of the supported (wildfly, thorntail, spring boot) runtimes.
Based upon our comments we would probably start with:
WildFly: standalone, docker
Thorntail: standalone, openshift
Spring Boot: standalone, openshift
> I'd expect docker instances to be persistently mutable. I'd envision wildfly with docker to be used two-fold:
1) This is similar to the JDV strategy - but there has always been contention around what is the appropriate way to configure EAP. Since this would be community only, we can show whatever makes sense for us: A base image, an directory structure of an overlay of modules and other files, cli files that get run as part, etc. My preference though would be to emphasize or start with 2 to avoid confusion or overlap with what JDV 6.4 and the new tooling is doing.
[~rareddy] any thoughts?
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-5343) Enable absolute URI on context definition of EntitySets when using ODATA
by Rafael Sampaio (JIRA)
[ https://issues.jboss.org/browse/TEIID-5343?page=com.atlassian.jira.plugin... ]
Rafael Sampaio commented on TEIID-5343:
---------------------------------------
Hi there Ramesh, sorry for the delay.
The change applied on https://issues.apache.org/jira/browse/OLINGO-1271 does fixes the reported problem and comunication with MS products runs smoothly. Thanks a lot.
> Enable absolute URI on context definition of EntitySets when using ODATA
> ------------------------------------------------------------------------
>
> Key: TEIID-5343
> URL: https://issues.jboss.org/browse/TEIID-5343
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Affects Versions: 10.2.1
> Reporter: Rafael Sampaio
> Assignee: Ramesh Reddy
> Fix For: 11.1
>
>
> Hi all you TEIID guys.
> As reported on [OLINGO-1025|https://issues.apache.org/jira/browse/OLINGO-1025], integrating to MS OData consumers (ie. PowerBI/PowerQuery) gives the "should be an absolute Uri" error.
> The proposed solution in the JIRA is implementing a Processor for any given EntityType. Browsing through the code i see TEIID uses the ServiceHandler approach, instead of processor and it also has a Custom JSON Odata Serializer.
> I see that the Default JSON serializer, when serializing entity collections uses the ContextURL to generate the context metadata for the EntityCollection, but by default it does not contain the service root, since it comes from static DataRequest.buildEntitySetContextURL(olingo) method.
> Would be nice if we could choose this behavior through a init param in the odata deployment.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-3907) Support compensating transactions for updatable non-XA sources
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3907?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3907:
----------------------------------
Fix Version/s: 11.1
(was: 11.0)
In starting to work this, it won't be as quick of feature as I had hoped so it won't fit into just 11.0. Pushing to 11.1.
> Support compensating transactions for updatable non-XA sources
> --------------------------------------------------------------
>
> Key: TEIID-3907
> URL: https://issues.jboss.org/browse/TEIID-3907
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 11.1
>
>
> The transaction manager will fully support xa with all xa sources and a single local transaction resource. Beyond that however there is no built-in support for compensating transactions with non-XA sources. There has been work in Narayana on compensating transactions though that could be used by custom web apps consuming Teiid. We would like to eventually offer compensating options for some of our updatable non-XA sources, but it hasn't had sufficient priority yet.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-3907) Support compensating transactions for updatable non-XA sources
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3907?page=com.atlassian.jira.plugin... ]
Work on TEIID-3907 stopped by Steven Hawkins.
---------------------------------------------
> Support compensating transactions for updatable non-XA sources
> --------------------------------------------------------------
>
> Key: TEIID-3907
> URL: https://issues.jboss.org/browse/TEIID-3907
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 11.0
>
>
> The transaction manager will fully support xa with all xa sources and a single local transaction resource. Beyond that however there is no built-in support for compensating transactions with non-XA sources. There has been work in Narayana on compensating transactions though that could be used by custom web apps consuming Teiid. We would like to eventually offer compensating options for some of our updatable non-XA sources, but it hasn't had sufficient priority yet.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-5372) Enhance docker support
by Rafal Korytkowski (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Rafal Korytkowski commented on TEIID-5372:
------------------------------------------
Great, I could work on a page describing different deployment models some time next week and put it under Teiid 4 Ways.
I'd expect docker instances to be persistently mutable. I'd envision wildfly with docker to be used two-fold:
1) As a base docker image with vdbs, drivers and config added as part of a docker build in Dockerfile.
2) As a docker instance with vdbs, drivers and config read from a mounted volume using wildfly deployment scanner or loaded other ways into a running instance.
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-5386) Wrong procedure import from MS SQL Server
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/TEIID-5386?page=com.atlassian.jira.plugin... ]
Jan Martiska commented on TEIID-5386:
-------------------------------------
This was JDBC driver version 4.0, I now tried the same with version 6.4, but no difference:
{noformat}
Commit=true;DatabaseProductName=Microsoft SQL Server;DatabaseProductVersion=13.00.4001;DriverMajorVersion=6;DriverMajorVersion=4;DriverName=Microsoft JDBC Driver 6.4 for SQL Server;DriverVersion=6.4.0.0;IsolationLevel=2
{noformat}
> Wrong procedure import from MS SQL Server
> -----------------------------------------
>
> Key: TEIID-5386
> URL: https://issues.jboss.org/browse/TEIID-5386
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.13.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> When using automatic procedure import from SQL Server (I used 2016) with a model like this:
> {noformat}
> <model name="mymodel">
> <property name="importer.useFullSchemaName" value="false"/>
> <property name="importer.UseQualifiedName" value="false" />
> <property name="importer.procedureNamePattern" value="echo%"/>
> <property name="importer.importProcedures" value="true" />
> <source connection-jndi-name="java:/mssql2016"
> name="mySource" translator-name="sqlserver" />
> </model>
> {noformat}
> There is a procedure named {{echo}} in SQL server. It is imported into the VDB as {{"mymodel"."echo;1"}} (not sure why the ;1). When I afterwards try to execute it using
> {noformat}
> EXEC "mymodel"."echo;1"();
> {noformat}, I will get this exception from SQL server which suggests that Teiid mapped the procedure to the wrong name in the source database:
> {noformat}
> com.microsoft.sqlserver.jdbc.SQLServerException: Could not find stored procedure 'echo;1'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (TEIID-5392) Define how other artifacts are included in a vdb archive
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5392?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5392:
---------------------------------------
> can someone list all the known directories and contents runtime recognizes?
The VDBRESOURCES system admin table allowed access to anything in the vdb archive - there was no expectation of where in the archive structure. We could start putting constraints on that though.
The lib directory it the one with explicit meaning.
xsd files no longer have any special meaning. They were part of the xml document model metadata.
> Define how other artifacts are included in a vdb archive
> --------------------------------------------------------
>
> Key: TEIID-5392
> URL: https://issues.jboss.org/browse/TEIID-5392
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
>
> An example throntail build should show how to incorporate udf jar(s) or other vdb resources.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months