[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ]
Juraj Duráni updated TEIID-3562:
--------------------------------
Attachment: out_GMT_not_set
out_GMT+0500
Main.java
Sorry for late response.
My steps (vdb [1]):
- default timezone (GMT+01:00 in my case)
1. run server with default timezone (no -Duser.timezone property in JAVA_OPTS)
2. run Main.java (out_GMT_not_set)
- timezone GMT+05:00
1. add -Duser.timezone=GMT+05:00 to JAVA_OPTS in bin/standalone.conf
2. run server
3. run Main.java with additional system property -Duser.timezone=GMT+05:00 (out_GMT+0500)
I think that this could be a driver issue partially - "get*(int,Calendar) - default TimeZone" return time/date/timestamp which is already shifted, so teradata driver expects that value is stored in GMT and shifts it. As far as I can say, data in the Teradata are stored without information about timezone.
However, "Teradata - get*(int)" return original value, but "Teiid_teradata - get*(int)" return shifted value. Is this expected behavior?
[1]
{code:xml}
<vdb name="test" version="1">
<model name="tera">
<source name="teradata" translator-name="teradata" connection-jndi-name="java:/TeradataDS" />
<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE smalla(IntKey integer,
DateValue date,
TimeValue time,
TimestampValue timestamp);
]]>
</metadata>
</model>
<model name="my">
<source name="mysql" translator-name="mysql5" connection-jndi-name="java:/MySQL55_PushDS" />
<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE smalla(IntKey integer,
DateValue date,
TimeValue time,
TimestampValue timestamp);
]]>
</metadata>
</model>
<model name="pos">
<source name="postgres" translator-name="postgresql" connection-jndi-name="java:/postgres92" />
<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE smalla(IntKey integer,
DateValue date,
TimeValue time,
TimestampValue timestamp);
]]>
</metadata>
</model>
<model name="ora">
<source name="oracle" translator-name="oracle" connection-jndi-name="java:/Oracle12_PushDS" />
<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE smalla(IntKey integer,
DateValue date,
TimeValue time,
TimestampValue timestamp);
]]>
</metadata>
</model>
</vdb>
{code}
> 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-3515) make makedep and related hints consistent
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3515?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3515:
---------------------------------------
Added commits to not preform the full join pushdown and to have makeind equivalent in options to makedep. So that just leaves making the comment and keyword forms of the hints equivalent.
> make makedep and related hints consistent
> -----------------------------------------
>
> Key: TEIID-3515
> URL: https://issues.jboss.org/browse/TEIID-3515
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> There are three places where hints can be specified, in the options clause, after an item, and before in a comment block.
> We should ensure that the comment block supports all options max/join for makedep, and that makeind should have the same options as makedep.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3524) Database Logging not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3524?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3524:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1231050|https://bugzilla.redhat.com/show_bug.cgi?id=1231050] from ON_QA to VERIFIED
> Database Logging not working
> ----------------------------
>
> Key: TEIID-3524
> URL: https://issues.jboss.org/browse/TEIID-3524
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.11
>
>
> When using db logging in Teiid, nothing gets inserted into the db. Logs appear at server.log, but not in the db.
> I set up the logging as follows:
> Created java:/teiid-log-ds datasource.
> Added these to logging subsystem:
> {code:xml}
> <async-handler name="TEIID_COMMAND_LOG">
> <level name="DEBUG"/>
> <queue-length value="50"/>
> <overflow-action value="block"/>
> <subhandlers>
> <handler name="TEIID_JPA_LOG"/>
> </subhandlers>
> </async-handler>
> <async-handler name="TEIID_AUDIT_LOG">
> <level name="DEBUG"/>
> <queue-length value="50"/>
> <overflow-action value="block"/>
> <subhandlers>
> <handler name="TEIID_JPA_LOG"/>
> </subhandlers>
> </async-handler>
> <custom-handler name="TEIID_JPA_LOG" class="org.teiid.logger.DatabaseAppender" module="org.jboss.teiid.extensions">
> <level name="DEBUG"/>
> </custom-handler>
> <logger category="org.teiid.COMMAND_LOG">
> <level name="DEBUG"/>
> <handlers>
> <handler name="TEIID_COMMAND_LOG"/>
> </handlers>
> </logger>
> <logger category="org.teiid.AUDIT_LOG">
> <level name="DEBUG"/>
> <handlers>
> <handler name="TEIID_AUDIT_LOG"/>
> </handlers>
> </logger>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3506) Move downloads off of sourceforge
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3506?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3506.
-----------------------------------
Resolution: Done
Marking as resolved. We'll update the the link to previous releases as necessary.
> Move downloads off of sourceforge
> ---------------------------------
>
> Key: TEIID-3506
> URL: https://issues.jboss.org/browse/TEIID-3506
> Project: Teiid
> Issue Type: Quality Risk
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> We need to move our downloads off of sourceforge onto an infrastructure we have more control over. This can be as simple as just pointing to the maven artifacts (which means that the server uber dist needs added) or we can start using the jboss.org download site.
> More than likely we'll leave the old downloads in place.
--
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 resolved TEIID-3562.
-----------------------------------
Resolution: Cannot Reproduce Bug
This wasn't locally reproducible for me.
> 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
>
> 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-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 commented on TEIID-3536:
------------------------------------
The problem was that the cache key object type (String) was different than the attribute that was used as the primary key (integer). The tool that inserted the initial rows used a string value. And when the teiid logic tried to remove them, it was using an integer to find them (which it didn't).
To resolve this, the CacheTypeMap property will be enhanced. The current format is:
cacheName:className[;pkFieldName]
Changing it so that the object type of the "pkFieldName" can be specified. So changing the format to:
cacheName:className[;pkFieldName[:cacheKeyJavaType]]
And only when specified, the key value will be transformed to this type before doing a lookup by key (i.e, for updates and deletes) or insert.
> 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
> 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-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 commented on TEIID-3533:
------------------------------------
Here's the error message that is seen when the boolean value isn't specified (or no default is set):
Error: Remote org.teiid.core.TeiidException: org.hibernate.search.bridge.BridgeException: Exception while calling bridge#set
class: org.infinispan.query.remote.indexing.ProtobufValueWrapper
path:
SQLState: 38000
ErrorCode: 0
> 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-3492) Provide a mechanism for users to modify the salesforce api version
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3492?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3492:
---------------------------------------
It looks like the simplest paths would be removal of the sf jars, or inclusion of multiple versions.
It looks like even if we could try to make the connector only dependent upon the wsc jar, that it could still be a problem in that the partner api jar can be version dependent upon the wsc jar. Also moving the PartnerConnection out of connector layer to be statefully held in the executions would loose a lot of the benefit of pooling the connections.
> Provide a mechanism for users to modify the salesforce api version
> ------------------------------------------------------------------
>
> Key: TEIID-3492
> URL: https://issues.jboss.org/browse/TEIID-3492
> Project: Teiid
> Issue Type: Feature Request
> Components: Salesforce Connector
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> We should provide a mechanism to easily target a different salesforce api version. We are currently defaulting to v22, which is quite old. The version change must be controlled as the metadata and the sf jars can be incompatible - if you for example build a model from v22, then you must stay on v22, and then recreate the model once you want to move to a later version.
> Currently the update procedure would be to copy/modify the salesforce translator module and have it point to newer wsc and partner api jars (which are java api compatible from what I have seen) and then change the any salesforce resource adapters to use the new api url.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3567) Create a combined example for use hadoop hdfs as a datasource
by Kylin Soong (JIRA)
Kylin Soong created TEIID-3567:
----------------------------------
Summary: Create a combined example for use hadoop hdfs as a datasource
Key: TEIID-3567
URL: https://issues.jboss.org/browse/TEIID-3567
Project: Teiid
Issue Type: Task
Affects Versions: 8.12
Reporter: Kylin Soong
Assignee: Kylin Soong
Fix For: 8.12
Current we can connect/transform/integrate Big data product like Hive, HBase, Spark via HBase translator, Hive translator, this example will demonstrate teiid connect/transform/integrate with Hive, HBase, Spark.
Phoenix only work with Hadoop 2.x, this example will demonstrate Hive translator + HBase + Hadoop 1.x
This example will demonstrate Hive translator + Spark + Hadoop
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (TEIID-3567) Create a combined example for use hadoop hdfs as a datasource
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3567?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-3567:
-------------------------------
Description:
Current we can connect/transform/integrate Big data product like Hive, HBase, Spark via HBase translator, Hive translator, this example will demonstrate this.
Phoenix only work with Hadoop 2.x, this example will demonstrate Hive translator + HBase + Hadoop 1.x
This example will demonstrate Hive translator + Spark + Hadoop
was:
Current we can connect/transform/integrate Big data product like Hive, HBase, Spark via HBase translator, Hive translator, this example will demonstrate teiid connect/transform/integrate with Hive, HBase, Spark.
Phoenix only work with Hadoop 2.x, this example will demonstrate Hive translator + HBase + Hadoop 1.x
This example will demonstrate Hive translator + Spark + Hadoop
> Create a combined example for use hadoop hdfs as a datasource
> -------------------------------------------------------------
>
> Key: TEIID-3567
> URL: https://issues.jboss.org/browse/TEIID-3567
> Project: Teiid
> Issue Type: Task
> Affects Versions: 8.12
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 8.12
>
>
> Current we can connect/transform/integrate Big data product like Hive, HBase, Spark via HBase translator, Hive translator, this example will demonstrate this.
> Phoenix only work with Hadoop 2.x, this example will demonstrate Hive translator + HBase + Hadoop 1.x
> This example will demonstrate Hive translator + Spark + Hadoop
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months