[JBoss JIRA] (TEIID-5221) OData4 Translator generates invalid metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5221?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5221:
---------------------------------------
> Well, I don't have much control over what I get as odata metadata.
[~jstastny] Then the metadata production may require an issue.
> What do I need to do to achieve the implicit match? Rename the FK column to match the referenced id?
To clarify things where things stand. A ReferentialConstraint will work:
{code}
<EntityType Name="A">
<Key>
<PropertyRef Name="a_id"/>
</Key>
<Property Name="a_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_value" Type="Edm.String" MaxLength="4000"/>
<NavigationProperty Name="C_FK0" Type="Collection(data.C)"/>
</EntityType>
<EntityType Name="C">
<Key>
<PropertyRef Name="c_id"/>
</Key>
<Property Name="c_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_ref" Type="Edm.Int32"/>
<NavigationProperty Name="FK0" Type="data.A">
<ReferentialConstraint Property="a_ref"
ReferencedProperty="a_id" />
</NavigationProperty>
</EntityType>
{code}
Only having the collection navigation and renaming the column will work:
{code}
<EntityType Name="A">
<Key>
<PropertyRef Name="a_id"/>
</Key>
<Property Name="a_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_value" Type="Edm.String" MaxLength="4000"/>
<NavigationProperty Name="C_FK0" Type="Collection(data.C)"/>
</EntityType>
<EntityType Name="C">
<Key>
<PropertyRef Name="c_id"/>
</Key>
<Property Name="c_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_id" Type="Edm.Int32"/>
</EntityType>
{code}
Unfortunately, if there is both the forward and reverse navigation the logic won't create the foreign key. So this won't work:
{code}
<EntityType Name="A">
<Key>
<PropertyRef Name="a_id"/>
</Key>
<Property Name="a_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_value" Type="Edm.String" MaxLength="4000"/>
<NavigationProperty Name="C_FK0" Type="Collection(data.C)"/>
</EntityType>
<EntityType Name="C">
<Key>
<PropertyRef Name="c_id"/>
</Key>
<Property Name="c_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_id" Type="Edm.Int32"/>
<NavigationProperty Name="FK0" Type="data.A"/>
</EntityType>
{code}
We hadn't seen an example of that last case (as it appears that frameworks generally assign the ReferentialConstraint), but I'm fine with implementing it.
> OData4 Translator generates invalid metadata
> ---------------------------------------------
>
> Key: TEIID-5221
> URL: https://issues.jboss.org/browse/TEIID-5221
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors, OData
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.3, 9.3.7, 8.12.12.6_4
>
>
> The OData V4 translator does not generate metadata correctly in situations
> 1) When multiple navigations are defined on the EnitityType.
> 2) The PSEDEO column usage is incorrect, as this should be only used with ComplexType structures when the association to EntityType is made. But this is also used in cases where incorrect referential constraints are used. This may lead to the additional columns on Entities which are hard to resolve during the runtime.
> 3) Usage of MERGE property is also incorrect when multiple navigation properties are defined as these may be overridden for (1)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-4650) SybaseIQ translator: week function can't be pushed directly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4650?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4650:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1549207
Bugzilla Update: Perform
> SybaseIQ translator: week function can't be pushed directly
> -----------------------------------------------------------
>
> Key: TEIID-4650
> URL: https://issues.jboss.org/browse/TEIID-4650
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.8.6_3
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Fix For: 9.1.2, 9.2
>
>
> SybaseIQ translator pushes WEEK function calls directly to SAP IQ. SAP IQ doesn't support such function. See [Date and Time Functions docs|http://help.sap.com/saphelp_iq1611_iqrefbb/helpdata/en/a5/2b07be84f2...]
> Query:
> {code:sql}
> SELECT WEEK(dateValue) FROM BQT1.SMALLA;
> {code}
> Pushed source query:
> {code:sql}
> [SELECT week(g_0."datevalue") FROM "bqt-server"."dvqe"."SmallA" AS g_0]
> {code}
> Error in logs:
> {code}
> 08:14:15,830 WARN [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue19) Connector worker process failed for atomic-request=PYp5BTTPF3pK.8.0.2: org.teiid.translator.jdbc.JDBCExecutionException: 504 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT week(g_0."datevalue") FROM "bqt-server"."dvqe"."SmallA" AS g_0]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:366)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_71]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_71]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_71]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_71]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_71]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> Caused by: com.sybase.jdbc4.jdbc.SybSQLException: SQL Anywhere Error -265: Procedure 'week' not found
> at com.sybase.jdbc4.tds.Tds.a(Unknown Source)
> at com.sybase.jdbc4.tds.Tds.nextResult(Unknown Source)
> at com.sybase.jdbc4.tds.Tds.getResultSetResult(Unknown Source)
> at com.sybase.jdbc4.tds.TdsCursor.open(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybPreparedStatement.executeQuery(Unknown Source)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123) [translator-jdbc-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-5130:
------------------------------------
[~jolee], [~shawkins]
I can't really tell. I don't know exactly, what is the expected behavior. What I tried (and the result does not follow my expectations) is:
# set the property to false via cli (no reload was requested)
# deploy the vdb above
# waiting for the deployment to fail
> Document/refine behavior of treating result parameter as the first parameter
> ----------------------------------------------------------------------------
>
> Key: TEIID-5130
> URL: https://issues.jboss.org/browse/TEIID-5130
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.5, 8.12.12.6_4
>
>
> DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position.
> We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5266) Docker Issue
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5266?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5266:
-------------------------------------
Make sure the port 31000, and 8080 are available on your machine. If there is another instance running, close that first or remove -p options on docker run
> Docker Issue
> -------------
>
> Key: TEIID-5266
> URL: https://issues.jboss.org/browse/TEIID-5266
> Project: Teiid
> Issue Type: Bug
> Reporter: Arvind Gopinath
> Assignee: Steven Hawkins
> Priority: Minor
> Attachments: Dockerfile, VDB-Teiid-RDBMS-ErrorLogs-Docker.txt
>
>
> For the below example - when I create the docker file (attached for reference) and run through docker, I am getting below error message -
> https://github.com/teiid/wildfly-swarm-teiid-examples/tree/master/rdbms-a...
> docker run -p 31000:31000 -p 8080:8080 teiid/vdb-rdbms-swarm:1.0
> Error logs (attached)
> 2018-02-27 11:30:33,947 ERROR [stderr] (main) java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.teiid.transport.jdbc: Failed to start serv
> ice
> 2018-02-27 11:30:33,949 ERROR [stderr] (main) at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> 2018-02-27 11:30:33,949 ERROR [stderr] (main) at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:113)
> 2018-02-27 11:30:33,950 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.start(Swarm.java:398)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5221) OData4 Translator generates invalid metadata
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5221?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-5221:
------------------------------------
[~shawkins] Well, I don't have much control over what I get as odata metadata. I am consuming a VDB exposed through odata4 on the same Teiid instance. What do I need to do to achieve the implicit match? Rename the FK column to match the referenced id?
> OData4 Translator generates invalid metadata
> ---------------------------------------------
>
> Key: TEIID-5221
> URL: https://issues.jboss.org/browse/TEIID-5221
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors, OData
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.3, 9.3.7, 8.12.12.6_4
>
>
> The OData V4 translator does not generate metadata correctly in situations
> 1) When multiple navigations are defined on the EnitityType.
> 2) The PSEDEO column usage is incorrect, as this should be only used with ComplexType structures when the association to EntityType is made. But this is also used in cases where incorrect referential constraints are used. This may lead to the additional columns on Entities which are hard to resolve during the runtime.
> 3) Usage of MERGE property is also incorrect when multiple navigation properties are defined as these may be overridden for (1)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5221) OData4 Translator generates invalid metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5221?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5221:
---------------------------------------
The metadata you have is not sufficient to determine foreign keys. You must either specify the ReferentialConstraint or have columns that implicitly match:
<NavigationProperty Name="FK0" Type="data.A">
<ReferentialConstraint Property="a_ref"
ReferencedProperty="a_id" />
</NavigationProperty>
However the logic currently only looks for implicit 1-1 relationships.
> OData4 Translator generates invalid metadata
> ---------------------------------------------
>
> Key: TEIID-5221
> URL: https://issues.jboss.org/browse/TEIID-5221
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors, OData
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.3, 9.3.7, 8.12.12.6_4
>
>
> The OData V4 translator does not generate metadata correctly in situations
> 1) When multiple navigations are defined on the EnitityType.
> 2) The PSEDEO column usage is incorrect, as this should be only used with ComplexType structures when the association to EntityType is made. But this is also used in cases where incorrect referential constraints are used. This may lead to the additional columns on Entities which are hard to resolve during the runtime.
> 3) Usage of MERGE property is also incorrect when multiple navigation properties are defined as these may be overridden for (1)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5221) OData4 Translator generates invalid metadata
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5221?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-5221:
------------------------------------
[~shawkins] There are no foreign keys being imported in 8.12.12.6_4. Tested with commits up to (including) 84cbf16b.
For following odata4 metadata:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<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="teiid5221data.1.data" Alias="data">
<EntityType Name="A">
<Key>
<PropertyRef Name="a_id"/>
</Key>
<Property Name="a_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_value" Type="Edm.String" MaxLength="4000"/>
<NavigationProperty Name="C_FK0" Type="Collection(data.C)"/>
</EntityType>
<EntityType Name="B">
<Key>
<PropertyRef Name="b_id"/>
</Key>
<Property Name="b_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="b_value" Type="Edm.String" MaxLength="4000"/>
<NavigationProperty Name="C_FK1" Type="Collection(data.C)"/>
</EntityType>
<EntityType Name="C">
<Key>
<PropertyRef Name="c_id"/>
</Key>
<Property Name="c_id" Type="Edm.Int32" Nullable="false"/>
<Property Name="a_ref" Type="Edm.Int32"/>
<Property Name="b_ref" Type="Edm.Int32"/>
<NavigationProperty Name="FK0" Type="data.A"/>
<NavigationProperty Name="FK1" Type="data.B"/>
</EntityType>
<EntityContainer Name="data">
<EntitySet Name="A" EntityType="data.A">
<NavigationPropertyBinding Path="C_FK0" Target="C"/>
</EntitySet>
<EntitySet Name="B" EntityType="data.B">
<NavigationPropertyBinding Path="C_FK1" Target="C"/>
</EntitySet>
<EntitySet Name="C" EntityType="data.C">
<NavigationPropertyBinding Path="FK0" Target="A"/>
<NavigationPropertyBinding Path="FK1" Target="B"/>
</EntitySet>
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
{code}
I get this metadata imported:
{code:sql}
===> SET NAMESPACE 'http://www.jboss.org/teiiddesigner/ext/odata/2012' AS teiid_odata;
CREATE FOREIGN TABLE A (
a_id integer NOT NULL OPTIONS (NATIVE_TYPE 'Edm.Int32'),
a_value string,
PRIMARY KEY(a_id)
) OPTIONS (UPDATABLE TRUE, "teiid_odata:NameInSchema" 'data.A', "teiid_odata:Type" 'ENTITY_COLLECTION');
CREATE FOREIGN TABLE B (
b_id integer NOT NULL OPTIONS (NATIVE_TYPE 'Edm.Int32'),
b_value string,
PRIMARY KEY(b_id)
) OPTIONS (UPDATABLE TRUE, "teiid_odata:NameInSchema" 'data.B', "teiid_odata:Type" 'ENTITY_COLLECTION');
CREATE FOREIGN TABLE C (
c_id integer NOT NULL OPTIONS (NATIVE_TYPE 'Edm.Int32'),
a_ref integer OPTIONS (NATIVE_TYPE 'Edm.Int32'),
b_ref integer OPTIONS (NATIVE_TYPE 'Edm.Int32'),
PRIMARY KEY(c_id)
) OPTIONS (UPDATABLE TRUE, "teiid_odata:NameInSchema" 'data.C', "teiid_odata:Type" 'ENTITY_COLLECTION');
{code}
> OData4 Translator generates invalid metadata
> ---------------------------------------------
>
> Key: TEIID-5221
> URL: https://issues.jboss.org/browse/TEIID-5221
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors, OData
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.3, 9.3.7, 8.12.12.6_4
>
>
> The OData V4 translator does not generate metadata correctly in situations
> 1) When multiple navigations are defined on the EnitityType.
> 2) The PSEDEO column usage is incorrect, as this should be only used with ComplexType structures when the association to EntityType is made. But this is also used in cases where incorrect referential constraints are used. This may lead to the additional columns on Entities which are hard to resolve during the runtime.
> 3) Usage of MERGE property is also incorrect when multiple navigation properties are defined as these may be overridden for (1)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5130:
---------------------------------------
> Steven Hawkins Is the change limited only to ws translator?
No. The system property is general. It doesn't appear that your system property is change is taking effect.
> What concerns me in the backport is, that class BinaryWSProcedureExecution.java is backported as a brand new class. I believe this is due to the different location of this class in upstream vs. 8.12.12.6_4.
Yes that needs corrected.
> Document/refine behavior of treating result parameter as the first parameter
> ----------------------------------------------------------------------------
>
> Key: TEIID-5130
> URL: https://issues.jboss.org/browse/TEIID-5130
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.5, 8.12.12.6_4
>
>
> DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position.
> We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5266) Docker Issue
by Arvind Gopinath (JIRA)
Arvind Gopinath created TEIID-5266:
--------------------------------------
Summary: Docker Issue
Key: TEIID-5266
URL: https://issues.jboss.org/browse/TEIID-5266
Project: Teiid
Issue Type: Bug
Reporter: Arvind Gopinath
Assignee: Steven Hawkins
Priority: Minor
Attachments: Dockerfile, VDB-Teiid-RDBMS-ErrorLogs-Docker.txt
For the below example - when I create the docker file (attached for reference) and run through docker, I am getting below error message -
https://github.com/teiid/wildfly-swarm-teiid-examples/tree/master/rdbms-a...
docker run -p 31000:31000 -p 8080:8080 teiid/vdb-rdbms-swarm:1.0
Error logs (attached)
2018-02-27 11:30:33,947 ERROR [stderr] (main) java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.teiid.transport.jdbc: Failed to start serv
ice
2018-02-27 11:30:33,949 ERROR [stderr] (main) at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
2018-02-27 11:30:33,949 ERROR [stderr] (main) at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:113)
2018-02-27 11:30:33,950 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.start(Swarm.java:398)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin... ]
Jan Stastny edited comment on TEIID-5130 at 2/27/18 4:12 AM:
-------------------------------------------------------------
[~shawkins] Is the change limited only to ws translator? Anyway, I tried on 8.12.12.6_4 and 9.3.7 with both virtual and foreign procedure, but the property doesn't seem to work.
I can deploy following vdbs:
{code:xml}
<vdb name="teiid5130" version="1">
<model name="View">
<source connection-jndi-name="java:/rest-swagger" name="test" translator-name="ws" />
<metadata type="DDL">
<![CDATA[
CREATE FOREIGN PROCEDURE resultParameterOnPosition1(out param1 string result, out param2 string);
CREATE FOREIGN PROCEDURE resultParameterOnPosition2(out param1 string, out param2 string result);
]]>
</metadata>
</model>
</vdb>
{code}
or
{code:xml}
<vdb name="teiid5130" version="1">
<model name="View" type="VIRTUAL">
<metadata type="DDL">
<![CDATA[
CREATE VIRTUAL PROCEDURE resultParameterOnPosition1(out param1 string result, out param2 string) AS
BEGIN
param1='1';
param2='2';
END
CREATE VIRTUAL PROCEDURE resultParameterOnPosition2(out param1 string, out param2 string result) AS
BEGIN
param1='1';
param2='2';
END
]]>
</metadata>
</model>
</vdb>
{code}
when I have following system property on server:
{code:xml}
<system-properties>
<property name="org.teiid.resultAnyPosition" value="false"/>
</system-properties>
{code}
[~jolee]
What concerns me in the backport is, that class BinaryWSProcedureExecution.java is backported as a brand new class. I believe this is due to the different location of this class in upstream vs. 8.12.12.6_4.
was (Author: jstastny):
[~shawkins] Is the change limited only to ws translator? Anyway, I tried on 8.12.12.6_4 with both virtual and foreign procedure, but the property doesn't seem to work.
I can deploy following vdbs:
{code:xml}
<vdb name="teiid5130" version="1">
<model name="View">
<source connection-jndi-name="java:/rest-swagger" name="test" translator-name="ws" />
<metadata type="DDL">
<![CDATA[
CREATE FOREIGN PROCEDURE resultParameterOnPosition1(out param1 string result, out param2 string);
CREATE FOREIGN PROCEDURE resultParameterOnPosition2(out param1 string, out param2 string result);
]]>
</metadata>
</model>
</vdb>
{code}
or
{code:xml}
<vdb name="teiid5130" version="1">
<model name="View" type="VIRTUAL">
<metadata type="DDL">
<![CDATA[
CREATE VIRTUAL PROCEDURE resultParameterOnPosition1(out param1 string result, out param2 string) AS
BEGIN
param1='1';
param2='2';
END
CREATE VIRTUAL PROCEDURE resultParameterOnPosition2(out param1 string, out param2 string result) AS
BEGIN
param1='1';
param2='2';
END
]]>
</metadata>
</model>
</vdb>
{code}
when I have following system property on server:
{code:xml}
<system-properties>
<property name="org.teiid.resultAnyPosition" value="false"/>
</system-properties>
{code}
[~jolee]
What concerns me in the backport is, that class BinaryWSProcedureExecution.java is backported as a brand new class. I believe this is due to the different location of this class in upstream vs. 8.12.12.6_4.
> Document/refine behavior of treating result parameter as the first parameter
> ----------------------------------------------------------------------------
>
> Key: TEIID-5130
> URL: https://issues.jboss.org/browse/TEIID-5130
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.5, 8.12.12.6_4
>
>
> DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position.
> We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months