[JBoss JIRA] (TEIID-3442) Apache Spark support via SparkSQL and DataFrames
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3442?page=com.atlassian.jira.plugin... ]
Kylin Soong resolved TEIID-3442.
--------------------------------
Resolution: Done
I set to resolved base on my above investigation.
> Apache Spark support via SparkSQL and DataFrames
> ------------------------------------------------
>
> Key: TEIID-3442
> URL: https://issues.jboss.org/browse/TEIID-3442
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.10
> Reporter: John Muller
> Assignee: Kylin Soong
> Labels: Connectors, Spark, Translators
> Fix For: 8.12
>
> Original Estimate: 20 weeks
> Remaining Estimate: 20 weeks
>
> Eliciting comments for Apache Spark support. With the release of Panda's like DataFrames, it is a little more feasible to directly translate to SparkSQL:
> https://spark.apache.org/docs/latest/sql-programming-guide.html
> Options in order of complexity:
> 1. Use the existing Hive connector / translator. Spark still uses the Hive metastore.
> 2. Thrift JDBC driver. This is what Microstrategy, Tableau, QlikView and others use, most rudimentary API for accessing Spark.
> 3. Native SparkSQL via building Spark jobs and submitting them to a running Spark driver.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3533) Infinispan-dsl-cache translator: can't insert value into BYTE and BIGINTEGER columns
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3533?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-3533:
-------------------------------
Git Pull Request: https://github.com/teiid/teiid/pull/488
> Infinispan-dsl-cache translator: can't insert value into BYTE and BIGINTEGER columns
> ------------------------------------------------------------------------------------
>
> Key: TEIID-3533
> URL: https://issues.jboss.org/browse/TEIID-3533
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Filip Elias
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
> Attachments: server.log, testVDB.vdb
>
>
> Sample query:
> {code}
> insert into smalla(intKey, byteNum) values(100,100);
> insert into smalla(intKey, BIGINTEGERVALUE) values(100,100);
> {code}
> Exception:
> {code}
> [org.teiid.CONNECTOR] (Worker9_QueryProcessorQueue59) Connector worker process failed for atomic-request=NuZ8Nt3h1bKx.20.0.13: java.lang.IllegalArgumentException: Conversion from String to java.math.BigDecimal is not supported
> at org.teiid.core.util.StringUtil.valueOf(StringUtil.java:797) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.core.util.PropertiesUtils.setProperty(PropertiesUtils.java:792) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.core.util.PropertiesUtils.setBeanProperty(PropertiesUtils.java:782) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.handleInsert(InfinispanUpdateExecution.java:204)
> {code}
> The VDB and the server log is attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3536) Infinispan-dsl-cache translator: Can't delete or update rows which were previously inserted through hotrod protocol
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3536?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-3536:
-------------------------------
Git Pull Request: https://github.com/teiid/teiid/pull/488
> Infinispan-dsl-cache translator: Can't delete or update rows which were previously inserted through hotrod protocol
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3536
> URL: https://issues.jboss.org/browse/TEIID-3536
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Filip Elias
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2
>
> Attachments: server1.log, server2.log
>
>
> Rows which have been inserted into cache directly through hotrod protocol can't be deleted or updated (update command returns correct number of rows to be updated but no rows are actually updated) using the Infinispan-dsl-cache translator.
> If the rows are inserted through Infinispan-dsl-cache translator, then they can be deleted or updated.
> Server1.log contains logs for an attempt to delete row which was previously directly inserted through hotrod protocol. It contains logs for two queries:
> 1, select * from smalla where intkey = 10 (returns 1 row)
> 2, delete from smalla where intkey = 10 (deletes 0 rows)
> Server2.log contains logs for an attempt to delete row which was inserted using the Infinispan-dsl-cache translator. It contains logs for two queries:
> 1, insert into smalla(intKey, stringKey,booleanValue) values(141,'ss',false) (correctly inserts 1 row)
> 2, delete from smalla where intkey = 10 (correctly deletes 1 row)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3535) Infinispan-dsl-cache translator: NPE when inserting data if a table doesn't have primary key defined
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3535?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-3535:
-------------------------------
Git Pull Request: https://github.com/teiid/teiid/pull/488
> Infinispan-dsl-cache translator: NPE when inserting data if a table doesn't have primary key defined
> ----------------------------------------------------------------------------------------------------
>
> Key: TEIID-3535
> URL: https://issues.jboss.org/browse/TEIID-3535
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Filip Elias
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
>
> Exception:
> {code}
> ERROR [org.teiid.CONNECTOR] (Worker12_QueryProcessorQueue194) Connector worker process failed for atomic-request=ziNYENHc9zCz.0.0.33: java.lang.NullPointerException
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.handleInsert(InfinispanUpdateExecution.java:149)
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.execute(InfinispanUpdateExecution.java:107)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:358) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:325) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3536) Infinispan-dsl-cache translator: Can't delete or update rows which were previously inserted through hotrod protocol
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3536?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-3536:
-------------------------------
Fix Version/s: 8.7.1.6_2
> Infinispan-dsl-cache translator: Can't delete or update rows which were previously inserted through hotrod protocol
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3536
> URL: https://issues.jboss.org/browse/TEIID-3536
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Filip Elias
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2
>
> Attachments: server1.log, server2.log
>
>
> Rows which have been inserted into cache directly through hotrod protocol can't be deleted or updated (update command returns correct number of rows to be updated but no rows are actually updated) using the Infinispan-dsl-cache translator.
> If the rows are inserted through Infinispan-dsl-cache translator, then they can be deleted or updated.
> Server1.log contains logs for an attempt to delete row which was previously directly inserted through hotrod protocol. It contains logs for two queries:
> 1, select * from smalla where intkey = 10 (returns 1 row)
> 2, delete from smalla where intkey = 10 (deletes 0 rows)
> Server2.log contains logs for an attempt to delete row which was inserted using the Infinispan-dsl-cache translator. It contains logs for two queries:
> 1, insert into smalla(intKey, stringKey,booleanValue) values(141,'ss',false) (correctly inserts 1 row)
> 2, delete from smalla where intkey = 10 (correctly deletes 1 row)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3568) Order By and Limit are not getting pushed to the database, when Union and join are used together.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3568?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3568:
---------------------------------------
If you are truly on 8.1, then the first thing to do would be to reproduce this in a later version - at least 8.7. Also what source are you hitting and what translator settings are being used?
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> --------------------------------------------------------------------------------------------------
>
> Key: TEIID-3568
> URL: https://issues.jboss.org/browse/TEIID-3568
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Reporter: Guru Prasad
> Assignee: Steven Hawkins
>
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> In this scenario there if the underlying table has millions of records the query never returns with data.
> *Query 1*: Using only Join without union, this works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> ) as u
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_0 LEFT OUTER JOIN ABC.CATEGORY AS g_1 ON g_0.EVTCATCODE = g_1.EVTCATCODE WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 2*: Using only Union without any join, this also works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTSYSID AS c_1, g_1.EVTUTCTOD AS c_2, g_1.EVTSYSTOD AS c_3, g_1.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) UNION ALL
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 3*: Using both Union and join, this does not push down the order by and limit.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> LEFT OUTER JOIN XYZ.EVTTYPE AS tp ON tp.evttypecode = u.evttypecode
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> ProjectNode(0) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> LimitNode(1) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] limit 8
> SortNode(2) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [SORT] [u.evtsysid]
> JoinNode(3) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evtcatcode=evtcatcode] output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> JoinNode(4) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evttypecode=evttypecode] output=[u.evtcatcode, u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod]
> AccessNode(5) output=[u.evttypecode, u.evtcatcode, u.evtsysid, u.evtutctod, u.evtsystod]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTCATCODE AS c_1, g_1.EVTSYSID AS c_2, g_1.EVTUTCTOD AS c_3, g_1.EVTSYSTOD AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> UNION ALL SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTCATCODE AS c_1, g_0.EVTSYSID AS c_2, g_0.EVTUTCTOD AS c_3, g_0.EVTSYSTOD AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> AccessNode(6) output=[evttypecode] SELECT g_0.EVTTYPECODE AS c_0 FROM ABC.EVTTYPE AS g_0 ORDER BY c_0
> AccessNode(7) output=[evtcatcode] SELECT g_0.EVTCATCODE AS c_0 FROM ABC.CATEGORY AS g_0 ORDER BY c_0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3568) Order By and Limit are not getting pushed to the database, when Union and join are used together.
by Guru Prasad (JIRA)
Guru Prasad created TEIID-3568:
----------------------------------
Summary: Order By and Limit are not getting pushed to the database, when Union and join are used together.
Key: TEIID-3568
URL: https://issues.jboss.org/browse/TEIID-3568
Project: Teiid
Issue Type: Bug
Affects Versions: 8.1
Reporter: Guru Prasad
Assignee: Steven Hawkins
Order By and Limit are not getting pushed to the database, when Union and join are used together.
In this scenario there if the underlying table has millions of records the query never returns with data.
*Query 1*: Using only Join without union, this works fine.
SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
) as u
LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
PROCESSOR PLAN:
AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_0 LEFT OUTER JOIN ABC.CATEGORY AS g_1 ON g_0.EVTCATCODE = g_1.EVTCATCODE WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
*Query 2*: Using only Union without any join, this also works fine.
SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
UNION ALL
select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
) as u
WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
PROCESSOR PLAN:
AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTSYSID AS c_1, g_1.EVTUTCTOD AS c_2, g_1.EVTSYSTOD AS c_3, g_1.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) UNION ALL
SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
*Query 3*: Using both Union and join, this does not push down the order by and limit.
SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
UNION ALL
select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
) as u
LEFT OUTER JOIN XYZ.EVTTYPE AS tp ON tp.evttypecode = u.evttypecode
LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
PROCESSOR PLAN:
ProjectNode(0) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
LimitNode(1) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] limit 8
SortNode(2) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [SORT] [u.evtsysid]
JoinNode(3) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evtcatcode=evtcatcode] output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
JoinNode(4) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evttypecode=evttypecode] output=[u.evtcatcode, u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod]
AccessNode(5) output=[u.evttypecode, u.evtcatcode, u.evtsysid, u.evtutctod, u.evtsystod]
SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTCATCODE AS c_1, g_1.EVTSYSID AS c_2, g_1.EVTUTCTOD AS c_3, g_1.EVTSYSTOD AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
UNION ALL SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTCATCODE AS c_1, g_0.EVTSYSID AS c_2, g_0.EVTUTCTOD AS c_3, g_0.EVTSYSTOD AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
AccessNode(6) output=[evttypecode] SELECT g_0.EVTTYPECODE AS c_0 FROM ABC.EVTTYPE AS g_0 ORDER BY c_0
AccessNode(7) output=[evtcatcode] SELECT g_0.EVTCATCODE AS c_0 FROM ABC.CATEGORY AS g_0 ORDER BY c_0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-3562 at 7/13/15 10:37 AM:
-----------------------------------------------------------------
> However, "Teradata - get*(int)" return original value, but "Teiid_teradata - get*(int)" return shifted value. Is this expected behavior?
Under the covers Teiid is getting the data/time/timestamp value using the get method with a calendar in the timezone of the server. So this behavior is coming straight from Terradata.
When I use version 13.0 of the client driver against the internal teradata instance in my default of Eastern Standard Time or explicitly set to GMT-5, then I see:
||intkey||datevalue||timevalue||timestampvalue||
|0|2000-01-01|00:00:00|2000-01-01 00:00:00.0|
Through Teiid, which seems like different behavior than you are seeing.
was (Author: shawkins):
> However, "Teradata - get*(int)" return original value, but "Teiid_teradata - get*(int)" return shifted value. Is this expected behavior?
Under the covers Teiid is getting the data/time/timestamp value using the get method with a calendar in the timezone of the server. So this behavior is coming straight from Terradata.
When I use version 13.0 of the client driver against the internal teradata instance in my default of Eastern Standard Time or explicitly set to GMT-5, then I see:
intkey datevalue timevalue timestampvalue
0 2000-01-01 00:00:00 2000-01-01 00:00:00.0
Through Teiid, which seems like different behavior than you are seeing.
> Teradata15 - teiid shifts date/time/timestamp values according to timezone.
> ---------------------------------------------------------------------------
>
> Key: TEIID-3562
> URL: https://issues.jboss.org/browse/TEIID-3562
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: teradata version - 15.00.01.01
> teradata driver version - 15.10.00.05
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: Main.java, out_GMT+0500, out_GMT_not_set
>
>
> Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3].
> [1]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+5
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0|
> |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0|
> |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0|
> |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0|
> |...|...|...|...|
> [2]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+1
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0|
> |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0|
> |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0|
> |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0|
> |...|...|...|...|
> [3]
> *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1
> *local timezone:* GMT+1/GMT+5
> *Result:*
> || c_0 || c_1 || c_2 || c_3 ||
> |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0|
> |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0|
> |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0|
> |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0|
> |...|...|...|...|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3562:
---------------------------------------
> However, "Teradata - get*(int)" return original value, but "Teiid_teradata - get*(int)" return shifted value. Is this expected behavior?
Under the covers Teiid is getting the data/time/timestamp value using the get method with a calendar in the timezone of the server. So this behavior is coming straight from Terradata.
When I use version 13.0 of the client driver against the internal teradata instance in my default of Eastern Standard Time or explicitly set to GMT-5, then I see:
intkey datevalue timevalue timestampvalue
0 2000-01-01 00:00:00 2000-01-01 00:00:00.0
Through Teiid, which seems like different behavior than you are seeing.
> Teradata15 - teiid shifts date/time/timestamp values according to timezone.
> ---------------------------------------------------------------------------
>
> Key: TEIID-3562
> URL: https://issues.jboss.org/browse/TEIID-3562
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: teradata version - 15.00.01.01
> teradata driver version - 15.10.00.05
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: Main.java, out_GMT+0500, out_GMT_not_set
>
>
> Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3].
> [1]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+5
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0|
> |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0|
> |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0|
> |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0|
> |...|...|...|...|
> [2]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+1
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0|
> |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0|
> |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0|
> |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0|
> |...|...|...|...|
> [3]
> *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1
> *local timezone:* GMT+1/GMT+5
> *Result:*
> || c_0 || c_1 || c_2 || c_3 ||
> |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0|
> |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0|
> |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0|
> |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0|
> |...|...|...|...|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months