[JBoss JIRA] (TEIID-2605) Optimization substitutes wrong column in where clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2605?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2605.
---------------------------------
> Optimization substitutes wrong column in where clause
> -----------------------------------------------------
>
> Key: TEIID-2605
> URL: https://issues.jboss.org/browse/TEIID-2605
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: z/OS
> Reporter: Jeff Hayes
> Assignee: Steven Hawkins
> Attachments: query_plan.txt, views.xml
>
>
> Optimization results in a query with a different column in the WHERE clause producing an empty result set.
> Full query plan is attached but the beginning and ending queries are shown below. Note that the subject column of the IN clause is SCOPEID but optimization changes it to AUTHID for some reason.
> USER COMMAND:
> SELECT * FROM SECURITY.SCPXREF AS CHORUS_B WHERE (CHORUS_B.SYSID = 'DE29') AND ((CHORUS_B.SCOPEID IN (SELECT SN5.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN5 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN4.SCOPEID FROM SECURITY.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))))) OR (CHORUS_B.SCOPEID IN (SELECT SN4.SCOPEID FROM SECURIT
> Y.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))) OR (CHORUS_B.SC
> OPEID IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.S
> CPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))) OR (CHORUS_B.SCOPEID IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEX
> T AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))) OR (CHORUS_B.SCOPEID = 'CHRDEPT1'))
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(10) output=[x.sysid AS sysid, x.scopeid AS authid, x.authid AS scopeid, x.authtype AS authtype] SELECT g_0.SYSID, g_0.SCO
> PEID, g_0.AUTHID, g_0.AUTHTYPE FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPXREF AS g_0 WHERE (g_0.SYSID = 'DE29') AND ((g_0.AUTHID IN
> (SELECT g_1.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_1 WHERE (g_1.SYSID = 'DE29') AND (g_1.NEXTREC IN (SELECT g_2
> .SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_2 WHERE (g_2.SYSID = 'DE29') AND (g_2.NEXTREC IN (SELECT g_3.SCOPEID FR
> OM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_3 WHERE (g_3.SYSID = 'DE29') AND (g_3.NEXTREC IN (SELECT g_4.SCOPEID FROM SECURITY
> _CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_4 WHERE (g_4.SYSID = 'DE29') AND (g_4.NEXTREC = 'CHRDEPT1'))))))))) OR (g_0.AUTHID IN (SELECT
> g_5.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_5 WHERE (g_5.SYSID = 'DE29') AND (g_5.NEXTREC IN (SELECT g_6.SCOPEI
> D FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_6 WHERE (g_6.SYSID = 'DE29') AND (g_6.NEXTREC IN (SELECT g_7.SCOPEID FROM SECU
> RITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_7 WHERE (g_7.SYSID = 'DE29') AND (g_7.NEXTREC = 'CHRDEPT1'))))))) OR (g_0.AUTHID IN (SELE
> CT g_8.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_8 WHERE (g_8.SYSID = 'DE29') AND (g_8.NEXTREC IN (SELECT g_9.SCOP
> EID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_9 WHERE (g_9.SYSID = 'DE29') AND (g_9.NEXTREC = 'CHRDEPT1'))))) OR (g_0.AUTH
> ID IN (SELECT g_10.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_10 WHERE (g_10.SYSID = 'DE29') AND (g_10.NEXTREC = 'C
> HRDEPT1'))) OR (g_0.AUTHID = 'CHRDEPT1'))
> The view definitions are shown below:
> <view name="SCPNEXT">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="nextrec" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT t.sysid, t.scopeid, t.nextrec
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT n.sysid, n.scopeid, n.nextrec
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPNEXT n
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> <view name="SCPXREF">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="authid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="authtype" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT sysid, scopeid, authid, authtype
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT x.sysid, x.scopeid, x.authid, x.authtype
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPXREF x
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> I guess the best way to test this is to define these views and run the input query with SHOWPLAN=DEBUG and see if the AUTHID substitution is occurring.
> Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 months, 1 week
[JBoss JIRA] (TEIID-3898) Add OrientDB translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3898?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3898:
---------------------------------------
It can be left open in the Open To Community bucket.
> Add OrientDB translator
> -----------------------
>
> Key: TEIID-3898
> URL: https://issues.jboss.org/browse/TEIID-3898
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Reporter: Don Krapohl
> Fix For: Open To Community
>
>
> My organization has high-performance analytics on OrientDB graph databases. We use Teiid for centralized governance, access, etc. It would be beneficial to us if Teiid could translate to the SQL-like OrientDb syntax. Because there are many SQL-like syntax components of OrientDB's REST endpoints this should be fairly straightforward.
> The OrientDB site is http://orientdb.com/. It's Apache 2 licensed, has a stable and mature community, has multiple releases, and provides multiple access methods (jdbc, odbc, REST). Work on the translator should not be wasted effort.
> I can assist with testing if it would be helpful and if the translator is started I can assist in dev.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (TEIID-3898) Add OrientDB translator
by Rafal Korytkowski (JIRA)
[ https://issues.jboss.org/browse/TEIID-3898?page=com.atlassian.jira.plugin... ]
Rafal Korytkowski commented on TEIID-3898:
------------------------------------------
Thanks [~don.krapohl]! [~shawkins], do you want to close the issue in such a case?
> Add OrientDB translator
> -----------------------
>
> Key: TEIID-3898
> URL: https://issues.jboss.org/browse/TEIID-3898
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Reporter: Don Krapohl
> Fix For: Open To Community
>
>
> My organization has high-performance analytics on OrientDB graph databases. We use Teiid for centralized governance, access, etc. It would be beneficial to us if Teiid could translate to the SQL-like OrientDb syntax. Because there are many SQL-like syntax components of OrientDB's REST endpoints this should be fairly straightforward.
> The OrientDB site is http://orientdb.com/. It's Apache 2 licensed, has a stable and mature community, has multiple releases, and provides multiple access methods (jdbc, odbc, REST). Work on the translator should not be wasted effort.
> I can assist with testing if it would be helpful and if the translator is started I can assist in dev.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (TEIID-5210) GitBook integration is broken
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5210?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5210:
---------------------------------------
Now that there seems to be consensus on this approach, the remaining links to gitbook.io need to be updated. This needs to be completed for:
* the legacy site
* the new site
* teiid quickstarts
* teiid spring boot
* the teiid readme
* teiid embedded examples
* wildfly swarm teiid example
* teiid tools
> GitBook integration is broken
> -----------------------------
>
> Key: TEIID-5210
> URL: https://issues.jboss.org/browse/TEIID-5210
> Project: Teiid
> Issue Type: Bug
> Components: Documentation
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 10.3
>
>
> GitBooks are no longer syncing to our github.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (TEIID-5330) FIRST_VALUE/LAST_VALUE/LEAD/LAG functions always try to return integer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-5330?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-5330:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1572224
Bugzilla Update: Perform
> FIRST_VALUE/LAST_VALUE/LEAD/LAG functions always try to return integer
> ----------------------------------------------------------------------
>
> Key: TEIID-5330
> URL: https://issues.jboss.org/browse/TEIID-5330
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12.13.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.3, 10.1.4, 10.2.2
>
>
> The FIRST_VALUE/LAST_VALUE/LEAD/LAG functions always try to return integer, no matter what the type of the column is.
> If integer can be cast to the target type, the query will successfully return, but the return type will be integer instead of the expected one. If integer cannot be cast to the requested type, the query will fail.
> For example, when running this against a CSV source and a string column:
> {noformat}
> SELECT FIRST_VALUE(stringkey) OVER (ORDER BY stringkey) FROM BQT1.smallA
> {noformat}
> This fails with:
> {noformat}
> 14:54:49,328 ERROR [org.teiid.TRANSPORT] (New I/O worker #2) TEIID40113 Unhandled exception, aborting operation: org.teiid.transport.ObjectEncoder$FailedWriteException: org.teiid.core.TeiidRuntimeException: TEIID20001 The modeled datatype integer for column 0 doesn't match the runtime type "java.lang.String". Please ensure that the column's modeled datatype matches the expected data.
> at org.teiid.transport.ObjectEncoder.handleDownstream(ObjectEncoder.java:136) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.jboss.netty.channel.Channels.write(Channels.java:704) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.write(Channels.java:671) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler$ObjectChannelImpl.write(SSLAwareChannelHandler.java:94) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.transport.SocketClientInstance.send(SocketClientInstance.java:94) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.transport.ServerWorkItem.sendResult(ServerWorkItem.java:135) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.transport.ServerWorkItem$1.onCompletion(ServerWorkItem.java:105) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:996) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:676) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:223) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:194) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
> Caused by: org.teiid.core.TeiidRuntimeException: TEIID20001 The modeled datatype integer for column 0 doesn't match the runtime type "java.lang.String". Please ensure that the column's modeled datatype matches the expected data.
> at org.teiid.client.BatchSerializer.writeBatch(BatchSerializer.java:878) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.ResultsMessage.writeExternal(ResultsMessage.java:319) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) [rt.jar:1.8.0_151]
> at org.teiid.net.socket.Message.writeExternal(Message.java:61) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) [rt.jar:1.8.0_151]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) [rt.jar:1.8.0_151]
> at org.teiid.transport.ObjectEncoder.handleDownstream(ObjectEncoder.java:131) [teiid-runtime-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> ... 25 more
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
> at org.teiid.client.BatchSerializer$IntColumnSerializer.writeObject(BatchSerializer.java:563) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.BatchSerializer$ColumnSerializer.writeColumn(BatchSerializer.java:534) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> at org.teiid.client.BatchSerializer.writeBatch(BatchSerializer.java:867) [teiid-client-8.12.13.6_4-redhat-64-1.jar:8.12.13.6_4-redhat-64-1]
> ... 36 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (TEIID-5331) LEAD/LAG ignores ORDER BY in the OVER clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5331?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5331.
-----------------------------------
Fix Version/s: 10.3
10.1.4
10.2.2
Resolution: Done
lead/lag were incorrectly implemented as row value functions (row_number), rather than normal window functions, which caused the logic to compute the wrong offset index for the lead/lag row.
> LEAD/LAG ignores ORDER BY in the OVER clause
> --------------------------------------------
>
> Key: TEIID-5331
> URL: https://issues.jboss.org/browse/TEIID-5331
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12.13.6_4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.3, 10.1.4, 10.2.2
>
>
> Consider the following query:
> {code:sql}
> select charvalue, intkey, lead(intkey, 1, NULL) over (order by charvalue, intkey) from smalla order by intkey
> {code}
> This is expected to mean that the database orders the rows by charvalue, then intkey, then for each row finds the lead value in the ordered data set, _then_ sorts all the results by intkey.
> Indeed, when run against e.g. postgres or oracle datasource, the results are as follows:
> ||charvalue||intkey||lead||
> |1|0|2|
> |0|1|3|
> |1|2|4|
> |0|3|5|
> |1|4|6|
> |...|...|...|
> The results are also the same when running the query against teiid with e.g. postgres datasource, as the lead/lag is pushed down.
> However, when run against teiid with datasource that does not support lead/lag pushdown (such as csv), the results are different:
> ||charvalue||intkey||lead||
> |1|0|1|
> |0|1|2|
> |1|2|3|
> |0|3|4|
> |1|4|5|
> |...|...|...|
> I. e. it appears that the ORDER BY in the OVER clause is ignored and the LEAD/LAG uses the (possibly arbitrary) ordering returned from the datasource (which in this case is actually sorted by intkey, but we've seen random ordering from other datasources such as couchbase).
> Please note that the same result comes from teiid even when removing either of the columns from the OVER (ORDER BY ...) clause, as well when removing the overall ORDER BY clause.
> Processor plan for the above query:
> {code}
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> ProjectNode(0) output=[A.CHARVALUE AS charvalue, A.INTKEY AS intkey, lead(A.INTKEY, 1, null) OVER (ORDER BY A.CHARVALUE, A.INTKEY)] [A.CHARVALUE AS charvalue, A.INTKEY AS intkey, lead(A.INTKEY, 1, null) OVER (ORDER BY A.CHARVALUE, A.INTKEY)]
> WindowFunctionProjectNode(1) output=[lead(A.INTKEY, 1, null) OVER (ORDER BY A.CHARVALUE, A.INTKEY), A.CHARVALUE, A.INTKEY]
> LimitNode(2) output=[A.CHARVALUE, A.INTKEY] limit 100
> SortNode(3) output=[A.CHARVALUE, A.INTKEY] [SORT] [A.INTKEY]
> JoinNode(4) [NESTED TABLE JOIN] [CROSS JOIN] output=[A.CHARVALUE, A.INTKEY]
> ProjectNode(5) output=[file] [sourceModel.getTextFiles.file]
> AccessNode(6) output=[sourceModel.getTextFiles.file, sourceModel.getTextFiles.filePath] EXEC sourceModel.getTextFiles('smallaCsv.csv')
> TextTableNode(7) output=[A.CHARVALUE, A.INTKEY]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (TEIID-5332) Change JDG translator/connector to package the jars and include in distro
by Van Halbert (JIRA)
Van Halbert created TEIID-5332:
----------------------------------
Summary: Change JDG translator/connector to package the jars and include in distro
Key: TEIID-5332
URL: https://issues.jboss.org/browse/TEIID-5332
Project: Teiid
Issue Type: Enhancement
Components: Infinispan
Affects Versions: 8.12.12.6_4
Reporter: Van Halbert
Assignee: Ramesh Reddy
Priority: Blocker
JDG will be deprecating their 7.1 images and moving to 7.2. So that the JDG translator can support 7.1 and future patching, JDV needs to package the jar's, instead of relying on the deprecated 7.1 client.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months