[
https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin...
]
Jan Stastny edited comment on TEIID-5130 at 2/27/18 3:52 AM:
-------------------------------------------------------------
[~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.
was (Author: jstastny):
[~shawkins] Is the change limited only to ws translator? Anyway, I tried on 8.12.12.6_4
and 9.3.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)