[
https://issues.jboss.org/browse/TEIID-4212?page=com.atlassian.jira.plugin...
]
Steven Hawkins resolved TEIID-4212.
-----------------------------------
Resolution: Rejected
There is no expectation that we should handle this conversion. If you leave the type
modeled as timestamp and perform a select, the value that you see from the teiid side
would include the appropriate time adjustment for the timezone - by modeling as a date you
are effectively throwing that information away. In general modeling narrower types that
aren't directly supported by the datasource is not recommended - the teiid type should
be at least as wide or wider than the source type.
Cassandra translator: pushing Date literal as # of milliseconds is
timezone dependent
-------------------------------------------------------------------------------------
Key: TEIID-4212
URL:
https://issues.jboss.org/browse/TEIID-4212
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 8.12.x
Reporter: Jan Stastny
Assignee: Steven Hawkins
Cassandra doesn't support Date datatype. To overcome this limitation Timestamp
datatype can be used on Cassandra's side in such a way that timestamp contains only
date-specific literals, others are zero, in Teiid's terms: \{ts '2000-02-02
00:00:00.0'\} for 2000-02-02.
In accordance with this workaround, it should be possible to query the tables in
Cassandra in such way:
{code:sql}
SELECT BQT1.SmallA.DateValue FROM BQT1.SmallA WHERE BQT1.SmallA.DateValue = {d
'2000-02-02'};
{code}
The date literal is pushed as # of milliseconds. And this is timezone dependent.
The query that gets pushed (timezone GMT+2):
{code:sql}
SELECT datevalue FROM smalla WHERE timestampvalue = 949464000000
{code}
And value 949446000000 is equivalent to 2000-02-02 in GMT+2 timezone.
Problem emerges, when the cassandra database is running in different timezone than teiid
server. Then the pushed 'date' value would not match the 'date' value in
cassandra (User can't specify TZ difference).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)