[JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3803:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1278817, https://bugzilla.redhat.com/show_bug.cgi?id=1278823 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1278817)
> Kerberos with ODBC with MutualAuth fails
> ----------------------------------------
>
> Key: TEIID-3803
> URL: https://issues.jboss.org/browse/TEIID-3803
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.12.x
>
>
> When Active Directory is used for Kerberos authentication, and Windows ODBC client issues connection request it may fail with following exception.
> {code}
> 00:29:15,561 ERROR [org.teiid.ODBC] (New I/O worker #19) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40014 Kerberos context login failed
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:203) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:236) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> Caused by: javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from teiid-security security domain; Expecting a Kerberoes response
> at org.teiid.jboss.JBossSessionService.buildGSSResult(JBossSessionService.java:138) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.jboss.JBossSessionService.neogitiateGssLogin(JBossSessionService.java:106) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:545) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:173) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> ... 30 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently according to timezone
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3808?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3808:
---------------------------------------
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
We are simply leveraging the driver's relevant get/set methods. There is no explicit check of the database server's timezone, rather the supply the Teiid server timezone or the database timezone via a Calendar. Typically if the default behavior is not as expected, then there may be a connection property or a set of session property that would make things more consistent. In this case I can't find anything after a cursory search.
Beyond this if one would need dates to be timezone sensitive and informix is not, then more than likely the required workaround would be to not model them as dates, but as strings or to have a view layer that introduces normalizing modifytimezone functions. So unless something else can be found, I'd say the resolution here is a KI that cautions about the inconsistencies of the informix driver/server.
> Informix translator - date/time/timestamp values are adjusted differently according to timezone
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-3808
> URL: https://issues.jboss.org/browse/TEIID-3808
> Project: Teiid
> Issue Type: Feature Request
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
> -------------------
> Server's timezone - GMT+1
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |05:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT+1
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 04:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT-1
> Result (int this case
> |time|date|timestamp|
> |23:00:00|2000-01-01|2000-01-01 06:00:00.0|
> Informix:
> {code:sql}
> ...
> datevalue date,
> timevalue datetime hour to fraction(1),
> timestampvalue datetime year to fraction(1),
> ...
> {code}
> VDB - foreign table:
> {code:sql}
> ...
> DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
> TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
> TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
> ...
> {code}
> VDB - view:
> {code:sql}
> ...
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> ...
> AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently according to timezone
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3808?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3808:
----------------------------------
Issue Type: Quality Risk (was: Feature Request)
> Informix translator - date/time/timestamp values are adjusted differently according to timezone
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-3808
> URL: https://issues.jboss.org/browse/TEIID-3808
> Project: Teiid
> Issue Type: Quality Risk
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
> -------------------
> Server's timezone - GMT+1
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |05:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT+1
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 04:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT-1
> Result (int this case
> |time|date|timestamp|
> |23:00:00|2000-01-01|2000-01-01 06:00:00.0|
> Informix:
> {code:sql}
> ...
> datevalue date,
> timevalue datetime hour to fraction(1),
> timestampvalue datetime year to fraction(1),
> ...
> {code}
> VDB - foreign table:
> {code:sql}
> ...
> DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
> TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
> TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
> ...
> {code}
> VDB - view:
> {code:sql}
> ...
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> ...
> AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3803:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1278817
Bugzilla Update: Perform
> Kerberos with ODBC with MutualAuth fails
> ----------------------------------------
>
> Key: TEIID-3803
> URL: https://issues.jboss.org/browse/TEIID-3803
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.12.x
>
>
> When Active Directory is used for Kerberos authentication, and Windows ODBC client issues connection request it may fail with following exception.
> {code}
> 00:29:15,561 ERROR [org.teiid.ODBC] (New I/O worker #19) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40014 Kerberos context login failed
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:203) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:236) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> Caused by: javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from teiid-security security domain; Expecting a Kerberoes response
> at org.teiid.jboss.JBossSessionService.buildGSSResult(JBossSessionService.java:138) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.jboss.JBossSessionService.neogitiateGssLogin(JBossSessionService.java:106) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:545) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:173) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> ... 30 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3807) quantified comparison results dependent on null ordering
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3807?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3807.
-----------------------------------
Resolution: Done
Corrected the logic so that we conditionally change the result.
> quantified comparison results dependent on null ordering
> --------------------------------------------------------
>
> Key: TEIID-3807
> URL: https://issues.jboss.org/browse/TEIID-3807
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.13, 8.12.2
>
>
> The handling of null and it's affect on the result is dependent upon it's position in the the subquery result.
> Specifically if null occurs before something that would otherwise evaluate to true for an all comparison the result will be true and not the expected null. Or if null occurs before something that would be otherwise false in a some comparison, then false will be returned rather than the expected null.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3627:
------------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1254053|https://bugzilla.redhat.com/show_bug.cgi?id=1254053] from MODIFIED to POST
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently according to timezone
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3808?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3808:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1278724
Bugzilla Update: Perform
> Informix translator - date/time/timestamp values are adjusted differently according to timezone
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-3808
> URL: https://issues.jboss.org/browse/TEIID-3808
> Project: Teiid
> Issue Type: Feature Request
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
> -------------------
> Server's timezone - GMT+1
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |05:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT+1
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 04:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT-1
> Result (int this case
> |time|date|timestamp|
> |23:00:00|2000-01-01|2000-01-01 06:00:00.0|
> Informix:
> {code:sql}
> ...
> datevalue date,
> timevalue datetime hour to fraction(1),
> timestampvalue datetime year to fraction(1),
> ...
> {code}
> VDB - foreign table:
> {code:sql}
> ...
> DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
> TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
> TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
> ...
> {code}
> VDB - view:
> {code:sql}
> ...
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> ...
> AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently acording to timezone
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-3808:
-----------------------------------
Summary: Informix translator - date/time/timestamp values are adjusted differently acording to timezone
Key: TEIID-3808
URL: https://issues.jboss.org/browse/TEIID-3808
Project: Teiid
Issue Type: Feature Request
Affects Versions: 8.7.1.6_2
Reporter: Juraj Duráni
Assignee: Steven Hawkins
The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
-------------------
Server's timezone - GMT+1
DatabaseTimeZone property - not overridden
Result:
|time|date|timestamp|
|01:00:00|2000-01-01|2000-01-01 00:00:00.0|
Server's timezone - GMT+5
DatabaseTimeZone property - not overridden
Result:
|time|date|timestamp|
|05:00:00|2000-01-01|2000-01-01 00:00:00.0|
Server's timezone - GMT+5
DatabaseTimeZone property - GMT+1
Result:
|time|date|timestamp|
|01:00:00|2000-01-01|2000-01-01 04:00:00.0|
Server's timezone - GMT+5
DatabaseTimeZone property - GMT-1
Result (int this case
|time|date|timestamp|
|23:00:00|2000-01-01|2000-01-01 06:00:00.0|
Informix:
{code:sql}
...
datevalue date,
timevalue datetime hour to fraction(1),
timestampvalue datetime year to fraction(1),
...
{code}
VDB - foreign table:
{code:sql}
...
DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
...
{code}
VDB - view:
{code:sql}
...
DateValue date,
TimeValue time,
TimestampValue timestamp,
...
AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently according to timezone
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3808?page=com.atlassian.jira.plugin... ]
Juraj Duráni updated TEIID-3808:
--------------------------------
Summary: Informix translator - date/time/timestamp values are adjusted differently according to timezone (was: Informix translator - date/time/timestamp values are adjusted differently acording to timezone)
> Informix translator - date/time/timestamp values are adjusted differently according to timezone
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-3808
> URL: https://issues.jboss.org/browse/TEIID-3808
> Project: Teiid
> Issue Type: Feature Request
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
> -------------------
> Server's timezone - GMT+1
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |05:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT+1
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 04:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT-1
> Result (int this case
> |time|date|timestamp|
> |23:00:00|2000-01-01|2000-01-01 06:00:00.0|
> Informix:
> {code:sql}
> ...
> datevalue date,
> timevalue datetime hour to fraction(1),
> timestampvalue datetime year to fraction(1),
> ...
> {code}
> VDB - foreign table:
> {code:sql}
> ...
> DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
> TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
> TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
> ...
> {code}
> VDB - view:
> {code:sql}
> ...
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> ...
> AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3802) HANA translator modifies boolean to tinyint in type conversion
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3802?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-3802:
-------------------------------------
Assignee: Ted Jones (was: Steven Hawkins)
Ted was the reasoning here that older Hana versions did not have a boolean type - http://scn.sap.com/thread/3323449
It looks like it does now - https://help.sap.com/saphelp_hanaplatform/helpdata/en/20/a1569875191014b5...
So we may need to just disallow usage of the convert function to boolean on older Hana instances.
> HANA translator modifies boolean to tinyint in type conversion
> --------------------------------------------------------------
>
> Key: TEIID-3802
> URL: https://issues.jboss.org/browse/TEIID-3802
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Ted Jones
>
> Teiid modifies boolean data type to tinyint before pushing the query down to the HANA instance.
> This brings following issue while having a query similar to this one:
> {code:sql}
> SELECT BQT1.SMallA.BooleanValue,cast(BQT2.SmallB.CharValue as boolean) FROM BQT1.SmallA,BQT2.SmallB WHERE BQT1.SmallA.BooleanValue = cast(BQT2.SmallB.CharValue as boolean)
> {code}
> which Teiid modifies to:
> {code:sql}
> SELECT g_0."BOOLEANVALUE", cast(g_1."CHARVALUE" AS tinyint) FROM "BQT1"."SMALLA" AS g_0, "BQT2"."SMALLB" AS g_1 WHERE g_0."BOOLEANVALUE" = cast(g_1."CHARVALUE" AS tinyint)
> {code}
> But the problem is not present for:
> {code:sql}
> SELECT BQT1.SMallA.BooleanValue FROM BQT1.SmallA WHERE BQT1.SmallA.BooleanValue = cast(BQT1.SmallA.CharValue as boolean)
> {code}
> It seems that the Cartesian product and comparing values from different sources are the cause of the issue. But HANA has internal type BOOLEAN, so there might be no point at modifying the type to TINYINT after all. I also checked, that the pushed query (which causes the issue) with the casting altered to BOOLEAN runs well on HANA. The following query returns expected results when pushed directly to HANA instance:
> {code:sql}
> SELECT g_0."BOOLEANVALUE", cast(g_1."CHARVALUE" AS boolean) FROM "BQT1"."SMALLA" AS g_0, "BQT2"."SMALLB" AS g_1 WHERE g_0."BOOLEANVALUE" = cast(g_1."CHARVALUE" AS boolean)
> {code}
> NOTE: The CharValue columns are modelled as VARCHAR/string in fact. Thus the cast is a valid operation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months