[JBoss JIRA] (TEIID-4553) COUNT returns inconsistent results when column statistics are not gathered
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4553?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4553:
---------------------------------
Fix Version/s: 8.12.9.6_3
> COUNT returns inconsistent results when column statistics are not gathered
> --------------------------------------------------------------------------
>
> Key: TEIID-4553
> URL: https://issues.jboss.org/browse/TEIID-4553
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0.6, 9.1.2, 9.2, 8.12.9.6_3
>
>
> I am experiencing a weird behavior in 9.1.0-Final. Depending if column statistics are gathered or not, a query with COUNT(1) generates different query plans and returns different results.
> For example, I defined two simple tables ds1.test_count_1 and ds2.test_count_2 having just a single column and one row with value 1.
> The following query:
> {code:sql}
> select count(1) from ds1.test_count_1 t1 join ds2.test_count_2 t2 on t1.a=t2.a group by t1.a
> {code}
> returns 4 with statistics and 2 without.
> This is the plan generated when statistics are gathered (the correct one):
> {code:sql}
> ProjectNode
> + Relational Node ID:1
> + Output Columns:expr1 (integer)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: 1.5
> + Child 0:
> GroupingNode
> + Relational Node ID:2
> + Output Columns:agg0 (integer)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: 1.5
> + Child 0:
> JoinNode
> + Relational Node ID:3
> + Output Columns:a (string)
> + Statistics:
> 0: Node Output Rows: 4
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: 2.8284268
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:a (string)
> + Statistics:
> 0: Node Output Rows: 2
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 0
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: 2.0
> + Query:SELECT g_0.a FROM ds1.test_count_1 AS g_0
> + Model Name:ds1
> + Child 1:
> AccessNode
> + Relational Node ID:5
> + Output Columns:a (string)
> + Statistics:
> 0: Node Output Rows: 2
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: 2.0
> + Query:SELECT g_0.a FROM ds2.test_count_2 AS g_0
> + Model Name:ds2
> + Join Strategy:ENHANCED SORT JOIN (SORT/SORT)
> + Join Type:INNER JOIN
> + Join Criteria:t1.a=t2.a
> + Grouping Columns:t1.a
> + Grouping Mapping:
> 0: anon_grp0.gcol0=t1.a
> 1: anon_grp0.agg0=COUNT(1)
> + Sort Mode:false
> + Select Columns:anon_grp0.agg0 AS expr1
> + Data Bytes Sent:17
> + Planning Time:3
> {code}
> and this is the one without statistics:
> {code:sql}
> ProjectNode
> + Relational Node ID:2
> + Output Columns:expr1 (integer)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> GroupingNode
> + Relational Node ID:3
> + Output Columns:agg0 (integer)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:4
> + Output Columns:gcol0 (string)
> + Statistics:
> 0: Node Output Rows: 2
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:5
> + Output Columns:gcol0 (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.a FROM ds1.test_count_1 AS g_0 GROUP BY g_0.a
> + Model Name:ds1
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:a (string)
> + Statistics:
> 0: Node Output Rows: 2
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 0
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.a FROM ds2.test_count_2 AS g_0
> + Model Name:ds2
> + Join Strategy:ENHANCED SORT JOIN (SORT/SORT)
> + Join Type:INNER JOIN
> + Join Criteria:anon_grp1.gcol0=t2.a
> + Grouping Columns:anon_grp1.gcol0
> + Grouping Mapping:
> 0: anon_grp0.gcol0=anon_grp1.gcol0
> 1: anon_grp0.agg0=COUNT(1)
> + Sort Mode:false
> + Select Columns:anon_grp0.agg0 AS expr1
> + Data Bytes Sent:17
> + Planning Time:4
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4580) ST_PointOnSurface returns point on the boundary of the polygon
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4580?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4580:
---------------------------------
Fix Version/s: 8.12.9.6_3
> ST_PointOnSurface returns point on the boundary of the polygon
> --------------------------------------------------------------
>
> Key: TEIID-4580
> URL: https://issues.jboss.org/browse/TEIID-4580
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.x, 8.12.7.6_3
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 9.1.2, 9.2, 8.12.9.6_3
>
>
> Calling ST_PointOnSurface with a polygon argument returns one of the points of the polygon boundary.
> E.g.
> {code:sql}
> SELECT ST_AsText(ST_PointOnSurface(ST_GeomFromText('POLYGON ((67 13, 67 18, 59 18, 59 13, 67 13))')));
> {code}
> returns {{POINT (67 13)}}
> The spec says
> bq. PointOnSurface( ):Point—A point guaranteed to be on this Surface.
> which might not be completely clear, but [several|http://gis.stackexchange.com/questions/76498/how-is-st-pointonsur...] [sources|http://workshops.boundlessgeo.com/postgis-intro/geometry_returnin...] indicate that "on this surface" means _inside_ the surface.
> When running the same query against a postgis instance (not through teiid), the result is {{POINT(63 15.5)}}, which is actually inside the polygon.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4627) High-level event handling
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4627?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4627:
---------------------------------------
Refinements that will be needed:
The old trigger logic assumes (like other databases) that views can only have 1 instead of trigger for each event type. This lead to us defining the trigger handling without an explicit name. Adding name handling will cause an issue with the event distributor logic (at the least new methods). A simpler approach will be to just not allow issuing a runtime create/alter for a source trigger. This also will imply that an explicit drop trigger, or enabled handling similar to the virtual layer, will not yet be needed either. Then we can work through the runtime issues in TEIID-2578
I'll need to separate out both a create and an alter trigger command statement to keep the logic cleaner.
The old trigger handling also did not treat the view triggers as first class entities (either at the schema level or as children of the table). Adding uids, allowing annotations, etc. and corresponding wiring in the system tables is all possible, but won't work for the view layer unless they are converted to proper objects as well.
> High-level event handling
> -------------------------
>
> Key: TEIID-4627
> URL: https://issues.jboss.org/browse/TEIID-4627
> Project: Teiid
> Issue Type: Enhancement
> Components: Grammar, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> We should look into high-level plugability of event handling at a row level. This could even be handled at the language level with new trigger semantics for source tables: create trigger on tbl on cdc (insert|update...) - which could potentially even specify the topic mapping other details. There is complexity for multi-source models here though.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4654) MSSQL pagination with select distinct
by Mark Tawk (JIRA)
Mark Tawk created TEIID-4654:
--------------------------------
Summary: MSSQL pagination with select distinct
Key: TEIID-4654
URL: https://issues.jboss.org/browse/TEIID-4654
Project: Teiid
Issue Type: Bug
Reporter: Mark Tawk
Assignee: Steven Hawkins
I'm using Teiid 9.0.0 with mssql translator on a sql server 2012 database
It seems sql server 2012 does not allow pagination with row fetch when used in select distinct query; i'm getting the following exception:
TEIID30504 dataModel_ptVDB: 145 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT DISTINCT g_0."Customer_ID" AS c_0, g_0."CalculatedField" AS c_1 FROM "data"."red4"."Customerview" g_0 ORDER BY @@version OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4617) Olap translator: Mondrian ClassNotFoundException moving from v 3.5.0 to 3.12.0
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4617?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4617:
---------------------------------------
Response from the ironjacamar forum is that there's no explicit requirement, so they would be reluctant to make a change.
> Olap translator: Mondrian ClassNotFoundException moving from v 3.5.0 to 3.12.0
> ------------------------------------------------------------------------------
>
> Key: TEIID-4617
> URL: https://issues.jboss.org/browse/TEIID-4617
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Attachments: Screenshot from 2016-12-05 07-49-16.png, mondrian.zip, olap4j.zip
>
>
> Change of version of Mondrian from 3.5.0 to 3.12.0 causes class not found exception.
> {code:plain}
> 07:44:03,800 WARN [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue10) Connector worker process failed for atomic-request=NFuIrbxSPuIu.0.3.3: org.teiid.translator.TranslatorException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS
> at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:87) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
> at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:45) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
> at org.teiid.translator.ExecutionFactory.getConnection(ExecutionFactory.java:202) [teiid-api-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:330)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_102]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_102]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy81.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:266) [rt.jar:1.8.0_102]
> 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:1142) [rt.jar:1.8.0_102]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:69)
> at org.teiid.translator.olap.OlapExecutionFactory.getConnection(OlapExecutionFactory.java:85) [translator-olap-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
> ... 20 more
> Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/mondrianDS
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:410)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:367)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:499)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:143)
> ... 22 more
> Caused by: javax.resource.ResourceException: IJ000658: Unexpected throwable while trying to create a connection: null
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:454)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:457)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:429)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:344)
> ... 25 more
> Caused by: javax.resource.ResourceException: Could not create connection
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:351)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:299)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:858)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:413)
> ... 28 more
> Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: mondrian.spi.impl.JndiDataSourceResolver from [Module "org.jboss.teiid.translator.olap:main" from local module loader @16f65612 (finder: local module finder @311d617d (roots: /home/jstastny/tmp-workspaces/workspace/modules,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/dv,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.9.CP,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base))]
> at mondrian.util.ClassResolver$AbstractClassResolver.instantiateSafe(ClassResolver.java:84)
> at mondrian.rolap.RolapConnection.getDataSourceResolver(RolapConnection.java:471)
> at mondrian.rolap.RolapConnection.createDataSource(RolapConnection.java:427)
> at mondrian.rolap.RolapConnection.<init>(RolapConnection.java:135)
> at mondrian.rolap.RolapConnection.<init>(RolapConnection.java:91)
> at mondrian.olap.DriverManager.getConnection(DriverManager.java:113)
> at mondrian.olap.DriverManager.getConnection(DriverManager.java:69)
> at mondrian.olap4j.MondrianOlap4jConnection.<init>(MondrianOlap4jConnection.java:162)
> at mondrian.olap4j.FactoryJdbc4Plus$AbstractConnection.<init>(FactoryJdbc4Plus.java:323)
> at mondrian.olap4j.FactoryJdbc41Impl$MondrianOlap4jConnectionJdbc41.<init>(FactoryJdbc41Impl.java:118)
> at mondrian.olap4j.FactoryJdbc41Impl.newConnection(FactoryJdbc41Impl.java:32)
> at mondrian.olap4j.MondrianOlap4jDriver.connect(MondrianOlap4jDriver.java:97)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:323)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: mondrian.spi.impl.JndiDataSourceResolver from [Module "org.jboss.teiid.translator.olap:main" from local module loader @16f65612 (finder: local module finder @311d617d (roots: /home/jstastny/tmp-workspaces/workspace/modules,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/dv,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.9.CP,/home/jstastny/tmp-workspaces/workspace/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_102]
> at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_102]
> at mondrian.util.ClassResolver$AbstractClassResolver.forName(ClassResolver.java:92)
> at mondrian.util.ClassResolver$AbstractClassResolver.instantiateSafe(ClassResolver.java:63)
> ... 43 more
> {code}
> But the class is present in the new version of Mondrian too, see attached screenshot with decompiled jar structure.
> One workaround I found was to add dependency into olap translator's module.xml pointing at the org.mondrian module, which contains the mondrian jar.
> But this action is not required when using Mondrian 3.5.0.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4653) SybaseIQ translator: Input parameter not set in prepared statement in source command
by Jan Stastny (JIRA)
Jan Stastny created TEIID-4653:
----------------------------------
Summary: 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: Bug
Components: Misc. Connectors
Affects Versions: 8.12.8.6_3
Reporter: Jan Stastny
Assignee: Steven Hawkins
Priority: Critical
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.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4652) SybaseIQ translator: DAYOFYEAR function not pushed correctly
by Jan Stastny (JIRA)
Jan Stastny created TEIID-4652:
----------------------------------
Summary: SybaseIQ translator: DAYOFYEAR function not pushed correctly
Key: TEIID-4652
URL: https://issues.jboss.org/browse/TEIID-4652
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 8.12.8.6_3
Reporter: Jan Stastny
Assignee: Steven Hawkins
DAYOFYEAR function is being pushed into SAP IQ datasource causing an error. The function doesn't seem to be supported directly in SAP IQ according to [SAP IQ docs|http://help.sap.com/saphelp_iq1611_iqrefbb/helpdata/en/a5/2b07be84f2...]
Query used:
{code:sql}
SELECT IntKey, datevalue, DAYOFYEAR(datevalue) AS DayFromDate FROM BQT1.SmallA ORDER BY IntKey
{code}
Source query pushed:
{code:sql}
[SELECT g_0."intkey" AS c_0, g_0."datevalue" AS c_1, {fn dayofyear(g_0."datevalue")} AS c_2 FROM "bqt-server"."dvqe"."SmallA" AS g_0 ORDER BY c_0]
{code}
Causing an error coming from SAP IQ:
{code}
09:08:30,130 WARN [org.teiid.CONNECTOR] (Worker11_QueryProcessorQueue58) Connector worker process failed for atomic-request=PYp5BTTPF3pK.20.0.12: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0."intkey" AS c_0, g_0."datevalue" AS c_1, {fn dayofyear(g_0."datevalue")} AS c_2 FROM "bqt-server"."dvqe"."SmallA" AS g_0 ORDER BY c_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: java.sql.SQLException: JZ0SI: A static function escape dayofyear was used which is not supported by this server.
at com.sybase.jdbc4.jdbc.ErrorMessage.raiseError(Unknown Source)
at com.sybase.jdbc4.jdbc.SybStatement.processEscapes(Unknown Source)
at com.sybase.jdbc4.jdbc.SybStatement.doEscapeProcessing(Unknown Source)
at com.sybase.jdbc4.jdbc.SybPreparedStatement.<init>(Unknown Source)
at com.sybase.jdbc4.jdbc.SybConnection.a(Unknown Source)
at com.sybase.jdbc4.jdbc.SybConnection.prepareStatement(Unknown Source)
at com.sybase.jdbc4.jdbc.SybConnection.prepareStatement(Unknown Source)
at com.sybase.jdbc4.jdbc.SybConnection.prepareStatement(Unknown Source)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.doPrepareStatement(BaseWrapperManagedConnection.java:744)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.prepareStatement(BaseWrapperManagedConnection.java:730)
at org.jboss.jca.adapters.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:405)
at org.teiid.translator.jdbc.JDBCBaseExecution.getPreparedStatement(JDBCBaseExecution.java:196) [translator-jdbc-8.12.8.6_3-redhat-1.jar:8.12.8.6_3-redhat-1]
at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:121) [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.2.3#72005)
9 years, 3 months
[JBoss JIRA] (TEIID-4651) SybaseIQ translator: different order of arguments in LOCATE function
by Jan Stastny (JIRA)
Jan Stastny created TEIID-4651:
----------------------------------
Summary: 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: Misc. Connectors
Affects Versions: 8.12.8.6_3
Reporter: Jan Stastny
Assignee: Steven Hawkins
Priority: Critical
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.2.3#72005)
9 years, 3 months