[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)
7 years, 10 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:
------------------------------------
[~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)
7 years, 10 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 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)
7 years, 10 months
[JBoss JIRA] (TEIID-4653) SybaseIQ translator: Input parameter not set in prepared statement in source command
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4653?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4653:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1549212
Bugzilla Update: Perform
> SybaseIQ translator: Input parameter not set in prepared statement in source command
> ------------------------------------------------------------------------------------
>
> Key: TEIID-4653
> URL: https://issues.jboss.org/browse/TEIID-4653
> Project: Teiid
> Issue Type: Sub-task
> Components: JDBC Connector
> Affects Versions: 8.12.8.6_3
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3, 9.2.1
>
>
> There seems to be problem with prepared statements which are being push to the datasource without binding parameters.
> The query engine fails with following error:
> {code}
> 13:08:00,044 WARN [org.teiid.CONNECTOR] (Worker18_QueryProcessorQueue72) Connector worker process failed for atomic-request=PYp5BTTPF3pK.25.0.16: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [{ts '2000-01-01 00:00:03.0'}] SQL: SELECT g_0."intkey", g_0."timestampvalue" FROM "bqt-server"."dvqe"."SmallA" AS g_0 WHERE g_0."timestampvalue" = ?]
> 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.GeneratedMethodAccessor169.invoke(Unknown Source) [: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: java.sql.SQLException: JZ0SA: Prepared Statement: Input parameter not set, index: 0.
> at com.sybase.jdbc4.jdbc.ErrorMessage.raiseError(Unknown Source)
> at com.sybase.jdbc4.tds.TdsParam.prepareForSend(Unknown Source)
> at com.sybase.jdbc4.jdbc.ParamManager.checkParams(Unknown Source)
> at com.sybase.jdbc4.tds.TdsCursor.a(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]
> ... 17 more
> {code}
> The message indicates, that a prepared statement which is being pushed has not bound parameter values set.
> h2.First Example
> Example query:
> {code:sql}
> SELECT IntKey, timestampvalue FROM BQT1.SmallA WHERE timestampvalue = TIMESTAMPCREATE( {d'2000-01-01'}, {t'00:00:03'})
> {code}
> Resulting DATA SRC COMMAND:
> {code:sql}
> SELECT g_0.intkey, g_0.timestampvalue FROM BQT1.SmallA AS g_0 WHERE g_0.timestampvalue = {ts'2000-01-01 00:00:03.0'}
> {code}
> Resulting SOURCE SRC COMMAND:
> {code:sql}
> [SELECT g_0."intkey", g_0."timestampvalue" FROM "bqt-server"."dvqe"."SmallA" AS g_0 WHERE g_0."timestampvalue" = ?]
> {code}
> h2. Second example
> Query:
> {code:sql}
> SELECT bqt2.smalla.intkey, g2.intkey, bqt2.smalla.bytenum FROM bqt2.smalla LEFT JOIN LATERAL (SELECT intkey FROM bqt2.mediuma WHERE bqt2.smalla.bytenum = bqt2.mediuma.bytenum) AS g2 ON true ORDER BY bqt2.smalla.intkey, g2.intkey
> {code}
> DATA SRC COMMAND 1:
> {code:sql}
> SELECT g_0.bytenum, g_0.intkey FROM BQT2.SmallA AS g_0
> {code}
> SOURCE SRC COMMAND 1:
> {code:sql}
> [SELECT g_0."bytenum", g_0."intkey" FROM "bqt-server"."dvqe"."SmallA" AS g_0]
> {code}
> DATA SRC COMMAND 2:
> {code:sql}
> SELECT g_0.intkey FROM BQT2.MediumA AS g_0 WHERE g_0.bytenum = -128
> {code}
> SOURCE SRC COMMAND 2:
> {code:sql}
> [SELECT g_0."intkey" FROM "bqt-server"."dvqe"."MediumA" AS g_0 WHERE g_0."bytenum" = ?]
> {code}
> h4.Note:
> There should be more DATA SRC commands similar to DATA SRC COMMAND 2, as such query should be performed in a loop for every result from DATA SRC COMMAND 1. But due to error in DATA SRC COMMAND 2, the loop is ended.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (TEIID-4651) SybaseIQ translator: different order of arguments in LOCATE function
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4651?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4651:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1549208
Bugzilla Update: Perform
> SybaseIQ translator: different order of arguments in LOCATE function
> --------------------------------------------------------------------
>
> Key: TEIID-4651
> URL: https://issues.jboss.org/browse/TEIID-4651
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.8.6_3
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1.2, 9.2, 8.12.11.6_4
>
>
> Teiid's and SAP IQ's LOCATE function differs in order of arguments. Translator is pushing the LOCATE function as is into the source, which results in undesirable results. This is critical issue, as the queries seemingly work, but are not producing correct results.
> See [SAP IQ LOCATE function docs|http://help.sap.com/saphelp_iq1611_iqrefbb/helpdata/en/a5/5fae8484f2...]
> Query:
> {code:sql}
> SELECT INTKEY, STRINGNUM, LOCATE(1,STRINGNUM) FROM BQT1.SmallA ORDER BY intkey
> {code}
> being pushed as:
> {code:sql}
> [SELECT g_0."intkey" AS c_0, g_0."stringnum" AS c_1, locate('1', g_0."stringnum") AS c_2 FROM "bqt-server"."dvqe"."SmallA" AS g_0 ORDER BY c_0]
> {code}
> Results in:
> || intkey || stringnum || expr3 ||
> |0 | -24 | 0|
> |1 | <null> | <null>|
> |2 | -22 | 0|
> |3 | -21 | 0|
> |4 | -20 | 0|
> |5 | -19 | 0|
> |6 | -18 | 0|
> |7 | -17 | 0|
> |8 | -16 | 0|
> |9 | -15 | 0|
> |10 | -14 | 0|
> |11 | -13 | 0|
> |12 | -12 | 0|
> |13 | -11 | 0|
> |14 | -10 | 0|
> |15 | -9 | 0|
> |16 | -8 | 0|
> |17 | <null> | <null>|
> |18 | -6 | 0|
> |19 | -5 | 0|
> |20 | -4 | 0|
> |21 | -3 | 0|
> |22 | -2 | 0|
> |23 | -1 | 0|
> |24 | 0 | 0|
> |25 | 1 | 1|
> |26 | 2 | 0|
> |27 | 3 | 0|
> |28 | 4 | 0|
> |29 | 5 | 0|
> |30 | 6 | 0|
> |31 | 7 | 0|
> |32 | 8 | 0|
> |33 | <null> | <null>|
> |34 | 10 | 0|
> |35 | 11 | 0|
> |36 | 12 | 0|
> |37 | 13 | 0|
> |38 | 14 | 0|
> |39 | 15 | 0|
> |40 | 16 | 0|
> |41 | 17 | 0|
> |42 | 18 | 0|
> |43 | 19 | 0|
> |44 | 20 | 0|
> |45 | 21 | 0|
> |46 | 22 | 0|
> |47 | 23 | 0|
> |48 | 24 | 0|
> |49 | <null> | <null> |
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (TEIID-5265) AssertionError: Batch not found in storage
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5265?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5265:
---------------------------------------
I can recreate something that looks like this by adding the cache entry, evicting the cache entry to disk, then re-adding the cache entry but with a larger size than before - which I believe can happen when we attempt to reuse the same page id in the tree logic. If this is the case, it should not be a hard error situation, but rather effectively remove the old entry and add the modified.
> AssertionError: Batch not found in storage
> ------------------------------------------
>
> Key: TEIID-5265
> URL: https://issues.jboss.org/browse/TEIID-5265
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 10.1
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
>
> While executing the following query:
> {code:sql}
> insert into rep149_cci(PatientID,age,Orig,Upd,agepointsO,agepointsU,AMI,CHF,PVD,CVD,DEM,CPD,PUD,MLD,SLD,DNC,DWC,HEM,RED,MAL,MST,HIV)
> select cci.patientid as patientid,cci.age as age,cci.orig as orig,cci.upd as upd,cci.agepointso as agepointso,cci.agepointsu as agepointsu,
> cci.charlson_ami as ami,cci.charlson_chf as chf,cci.charlson_pvd as pvd,cci.charlson_cvd as cvd,cci.charlson_dem as dem,cci.charlson_cpd as cpd,cci.charlson_pud as pud,
> cci.charlson_mld as mld,cci.charlson_sld as sld,cci.charlson_dnc as dnc,cci.charlson_dwc as dwc,cci.charlson_hem as hem,cci.charlson_red as red,cci.charlson_mal as mal,
> cci.charlson_mst as mst,cci.charlson_hiv as hiv
> from rep149_cohort gd
> join izisviews.pr_calculate_cci cci on
> cci.patientid_in = gd.patientid;
> {code}
> rep149_cci is defined as
> {code:sql}
> create foreign temporary table rep149_cci(
> PatientID integer not null,
> age bigdecimal,
> Orig long,
> Upd long,
> agepointsO integer,
> agepointsU integer,
> AMI integer,
> CHF integer,
> PVD integer,
> CVD integer,
> DEM integer,
> CPD integer,
> PUD integer,
> MLD integer,
> SLD integer,
> DNC integer,
> DWC integer,
> HEM integer,
> RED integer,
> MAL integer,
> MST integer,
> HIV integer,
> primary key(patientid)
> )OPTIONS (UPDATABLE true) on tmptables;
> {code}
> pr_calculate_cci is a virtual procedure. (I can't however share this code for confidentiality reasons).
> {code:sql}
> CREATE VIRTUAL PROCEDURE pr_calculate_cci(patientid_in integer)
> RETURNS (
> PatientID integer,
> age bigdecimal,
> Orig long,
> Upd long,
> agepointsO integer,
> agepointsU integer,
> AMI integer,
> CHF integer,
> PherVascDis integer,
> CerebVascDis integer,
> Dement integer,
> ChrPulmDis integer,
> PeptUlcer integer,
> MildLivDis integer,
> SevLivDis integer,
> DiabetesNoCompl integer,
> DiabetesWithCompl integer,
> HemiPara integer,
> RenalDis integer,
> Malign integer,
> Metastase integer,
> HIV_AIDS integer
> )
> AS
> BEGIN
> ...
> END
> {code}
> There are a few error reports like this one:
> 2018-02-23 08:33:05,478 ERROR [org.teiid.BUFFER_MGR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30001 Max block number exceeded by object 1,366,497 from group 5,068,016. It is a Batch of 1797 rows of [Ljava.lang.String;@10953478. The estimated size was 172,528, but the actual size was 14,410. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller.
> The final stack trace is:
> 2018-02-23 08:33:05,539 ERROR [org.teiid.PROCESSOR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30019 Unexpected exception for request mh0bsTIbs7qY.90: java.lang.AssertionError: Batch not found in storage 5067771
> at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:382)
> at org.teiid.common.buffer.SPage.getValues(SPage.java:234)
> at org.teiid.common.buffer.SPage.search(SPage.java:135)
> at org.teiid.common.buffer.STree.find(STree.java:247)
> at org.teiid.common.buffer.STree.insert(STree.java:295)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.saveValues(WindowFunctionProjectNode.java:419)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.buildResults(WindowFunctionProjectNode.java:380)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.nextBatchDirect(WindowFunctionProjectNode.java:229)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirectInternal(UnionAllNode.java:165)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirect(UnionAllNode.java:138)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:100)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160)
> at org.teiid.query.processor.relational.SourceState.prefetch(SourceState.java:207)
> at org.teiid.query.processor.relational.SourceState.rowCountLE(SourceState.java:154)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (TEIID-5265) AssertionError: Batch not found in storage
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5265?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5265:
---------------------------------------
Is that TEIID30001 the earliest such exception related to batch size/storage?
> AssertionError: Batch not found in storage
> ------------------------------------------
>
> Key: TEIID-5265
> URL: https://issues.jboss.org/browse/TEIID-5265
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 10.1
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
>
> While executing the following query:
> {code:sql}
> insert into rep149_cci(PatientID,age,Orig,Upd,agepointsO,agepointsU,AMI,CHF,PVD,CVD,DEM,CPD,PUD,MLD,SLD,DNC,DWC,HEM,RED,MAL,MST,HIV)
> select cci.patientid as patientid,cci.age as age,cci.orig as orig,cci.upd as upd,cci.agepointso as agepointso,cci.agepointsu as agepointsu,
> cci.charlson_ami as ami,cci.charlson_chf as chf,cci.charlson_pvd as pvd,cci.charlson_cvd as cvd,cci.charlson_dem as dem,cci.charlson_cpd as cpd,cci.charlson_pud as pud,
> cci.charlson_mld as mld,cci.charlson_sld as sld,cci.charlson_dnc as dnc,cci.charlson_dwc as dwc,cci.charlson_hem as hem,cci.charlson_red as red,cci.charlson_mal as mal,
> cci.charlson_mst as mst,cci.charlson_hiv as hiv
> from rep149_cohort gd
> join izisviews.pr_calculate_cci cci on
> cci.patientid_in = gd.patientid;
> {code}
> rep149_cci is defined as
> {code:sql}
> create foreign temporary table rep149_cci(
> PatientID integer not null,
> age bigdecimal,
> Orig long,
> Upd long,
> agepointsO integer,
> agepointsU integer,
> AMI integer,
> CHF integer,
> PVD integer,
> CVD integer,
> DEM integer,
> CPD integer,
> PUD integer,
> MLD integer,
> SLD integer,
> DNC integer,
> DWC integer,
> HEM integer,
> RED integer,
> MAL integer,
> MST integer,
> HIV integer,
> primary key(patientid)
> )OPTIONS (UPDATABLE true) on tmptables;
> {code}
> pr_calculate_cci is a virtual procedure. (I can't however share this code for confidentiality reasons).
> {code:sql}
> CREATE VIRTUAL PROCEDURE pr_calculate_cci(patientid_in integer)
> RETURNS (
> PatientID integer,
> age bigdecimal,
> Orig long,
> Upd long,
> agepointsO integer,
> agepointsU integer,
> AMI integer,
> CHF integer,
> PherVascDis integer,
> CerebVascDis integer,
> Dement integer,
> ChrPulmDis integer,
> PeptUlcer integer,
> MildLivDis integer,
> SevLivDis integer,
> DiabetesNoCompl integer,
> DiabetesWithCompl integer,
> HemiPara integer,
> RenalDis integer,
> Malign integer,
> Metastase integer,
> HIV_AIDS integer
> )
> AS
> BEGIN
> ...
> END
> {code}
> There are a few error reports like this one:
> 2018-02-23 08:33:05,478 ERROR [org.teiid.BUFFER_MGR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30001 Max block number exceeded by object 1,366,497 from group 5,068,016. It is a Batch of 1797 rows of [Ljava.lang.String;@10953478. The estimated size was 172,528, but the actual size was 14,410. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller.
> The final stack trace is:
> 2018-02-23 08:33:05,539 ERROR [org.teiid.PROCESSOR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30019 Unexpected exception for request mh0bsTIbs7qY.90: java.lang.AssertionError: Batch not found in storage 5067771
> at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:382)
> at org.teiid.common.buffer.SPage.getValues(SPage.java:234)
> at org.teiid.common.buffer.SPage.search(SPage.java:135)
> at org.teiid.common.buffer.STree.find(STree.java:247)
> at org.teiid.common.buffer.STree.insert(STree.java:295)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.saveValues(WindowFunctionProjectNode.java:419)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.buildResults(WindowFunctionProjectNode.java:380)
> at org.teiid.query.processor.relational.WindowFunctionProjectNode.nextBatchDirect(WindowFunctionProjectNode.java:229)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirectInternal(UnionAllNode.java:165)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirect(UnionAllNode.java:138)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:100)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160)
> at org.teiid.query.processor.relational.SourceState.prefetch(SourceState.java:207)
> at org.teiid.query.processor.relational.SourceState.rowCountLE(SourceState.java:154)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (TEIID-5252) Teiid Wildfly Swarm Odata
by Arvind Gopinath (JIRA)
[ https://issues.jboss.org/browse/TEIID-5252?page=com.atlassian.jira.plugin... ]
Arvind Gopinath closed TEIID-5252.
----------------------------------
All good. Thank you
> Teiid Wildfly Swarm Odata
> --------------------------
>
> Key: TEIID-5252
> URL: https://issues.jboss.org/browse/TEIID-5252
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Arvind Gopinath
> Assignee: Ramesh Reddy
> Priority: Minor
>
> Through Teiid Wildfly SWARM (examples code), I could able to run connecting below VDB and through SQL client, I could able to access my tables as well.
> To expose the same through Odata, in my pom.xml, I added below dependency.
> <dependency>
> <groupId>org.wildfly.swarm</groupId>
> <artifactId>odata</artifactId>
> <version>2018.1.0</version>
> </dependency>
> When my jar starts, I saw odata.war deployed and even my VDB added and through Sql client I could able to connect.
> 2018-02-08 15:30:31,119 INFO [org.jboss.as.server] (main) WFLYSRV0010: Deployed "odata.war" (runtime-name : "odata.war")
> 2018-02-08 15:30:31,493 INFO [org.teiid.RUNTIME.VDBLifeCycleListener] (MSC service thread 1-2) TEIID40118 VDB sqlite.1 added to the repository
> 2018-02-08 15:30:31,497 INFO [org.teiid.RUNTIME] (MSC service thread 1-2) TEIID50029 VDB sqlite.1 model "client" metadata is currently being loaded. Start Time: 8/02/18 3:30 PM
> But when I hit the URL,
> http://localhost:8080/odata4/sqlite.1/client.client
> I am getting error message below - Is it something I am missing?
> { "error": { "code": "38000", "message": "38000 TEIID10036 org.teiid.core.TeiidException: TEIID10036 org.teiid.core.TeiidRuntimeException: TEIID40067 javax.naming.NameNotFoundException: teiid\/queryengine\/odata -- service jboss.naming.context.java.teiid.queryengine.odata" } }
> Teiid Designer - Generated simple VDB.xml
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="sqlite" version="1">
> <description>SQLite VDB</description>
> <model name="client">
> <property name="importer.useFullSchemaName" value="false"/>
> <!-- https://access.redhat.com/documentation/en-us/red_hat_jboss_data_virtuali... -->
> <!-- <property name="importer.tableNamePattern" value="CLI%"/> -->
> <property name="importer.excludeTables" value="FIL.*|ORDER.*"/>
> <source name="sqlite-connector" translator-name="jdbc-simple" connection-jndi-name="java:jboss/datasources/demoDS"/>
> </model>
> </vdb>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months