[JBoss JIRA] (TEIID-4742) Provide query prioritization feature
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4742?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4742.
-----------------------------------
Fix Version/s: (was: 10.3)
Resolution: Incomplete Description
Marking as incomplete description. There is nothing specific here to determine what new strategy should be adopted and the product issue has been closed. There is already queuing of work beyond the max active plans, time slicing, queuing of engine work, and potentially waiting for source connections. Engine work does have a concept of prioritization, but it at a very low level mostly for allowing async source closure to happen faster (it will get queued ahead of other pending work).
> Provide query prioritization feature
> ------------------------------------
>
> Key: TEIID-4742
> URL: https://issues.jboss.org/browse/TEIID-4742
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Van Halbert
>
> as the system’s utilization surges, query prioritization, queuing and resource scaling will dynamically manage the added load without degrading or crashing the system or impacting essential / critical mission operations
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ]
Work on TEIID-5285 started by Steven Hawkins.
---------------------------------------------
> Add high-level feature for redirection of updates
> -------------------------------------------------
>
> Key: TEIID-5285
> URL: https://issues.jboss.org/browse/TEIID-5285
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Teiid Spring Boot
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.3
>
>
> In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates.
> Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5312) NullPointerException thrown when the second time login via GSS API
by Yuming Zhu (JIRA)
Yuming Zhu created TEIID-5312:
---------------------------------
Summary: NullPointerException thrown when the second time login via GSS API
Key: TEIID-5312
URL: https://issues.jboss.org/browse/TEIID-5312
Project: Teiid
Issue Type: Bug
Affects Versions: 8.12.12.6_3
Reporter: Yuming Zhu
Assignee: Steven Hawkins
The error was thrown when trying to login at the second time
ODBC:
{code}
09 Apr 2018 09:14:39,941 ERROR [org.teiid.ODBC] (New I/O worker #31) TEIID40015 Unexpected error occurred: java.lang.NullPointerException
at org.teiid.jboss.JBossSecurityHelper.buildGSSResult(JBossSecurityHelper.java:211) [teiid-jboss-integration-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.jboss.JBossSecurityHelper.negotiateGssLogin(JBossSecurityHelper.java:186) [teiid-jboss-integration-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:560) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:207) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:249) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_161]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_161]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161]
at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-redhat-1]
at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:216) [teiid-runtime-8.12.12.6_3-redhat-1.jar:8.12.12.6_3-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:303) [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$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:303) [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:1149) [rt.jar:1.8.0_161]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_161]
{code}
JDBC:
{code}
2018-04-09 09:43:06,333 INFO [org.teiid.SECURITY] (New I/O worker #13:) TEIID40017 Unexpected exception for session null: java.lang.NullPointerException
at org.teiid.jboss.JBossSecurityHelper.buildGSSResult(JBossSecurityHelper.java:211)
at org.teiid.jboss.JBossSecurityHelper.negotiateGssLogin(JBossSecurityHelper.java:186)
at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:560)
at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:207)
at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.teiid.transport.ServerWorkItem.run(ServerWorkItem.java:87)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
at org.teiid.transport.SocketClientInstance.processMessagePacket(SocketClientInstance.java:231)
at org.teiid.transport.SocketClientInstance.receivedMessage(SocketClientInstance.java:217)
at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:216)
at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:142)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
security-domain config:
{code:xml}
<security-domain name="REDHAT.COM" cache-type="default">
<authentication>
<login-module code="SPNEGO" flag="requisite">
<module-option name="password-stacking" value="useFirstPass" />
<module-option name="serverSecurityDomain" value="host" />
<module-option name="removeRealmFromPrincipal" value="true"/>
</login-module>
<login-module code="LdapExtended" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<module-option name="java.naming.provider.url" value="ldap://ldap.corp.redhat.com:389/"/>
<module-option name="java.naming.security.authentication" value="none"/>
<module-option name="baseCtxDN" value="ou=Users,dc=redhat,dc=com"/>
<module-option name="baseFilter" value="(&(objectClass=person)(uid={0}))"/>
<module-option name="rolesCtxDN" value="ou=Groups,dc=redhat,dc=com"/>
<module-option name="roleFilter" value="(&(objectClass=posixGroup)(memberUid={0}))"/>
<module-option name="roleAttributeID" value="cn"/>
<module-option name="searchScope" value="ONELEVEL_SCOPE"/>
</login-module>
<login-module code="RoleMapping" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="rolesProperties" value="file:/opt/jboss-eap/standalone/configuration/redhat-mapping-roles.properties"/>
</login-module>
<login-module code="UsersRoles" flag="required">
<module-option name="password-stacking" value="useFirstPass" />
<module-option name="usersProperties" value="file:/opt/jboss-eap/standalone/configuration/redhat-users.properties" />
<module-option name="rolesProperties" value="file:/opt/jboss-eap/standalone/configuration/redhat-roles.properties" />
</login-module>
</authentication>
</security-domain>
<security-domain name="host" cache-type="default">
<authentication>
<login-module code="Kerberos" flag="required">
<module-option name="storeKey" value="true" />
<module-option name="useKeyTab" value="true" />
<module-option name="principal" value="postgres/teiid.host.dev.eng.pek2.redhat.com(a)REDHAT.COM" />
<module-option name="keyTab" value="/opt/jboss-eap/standalone/configuration/postgres.keytab" />
<module-option name="doNotPrompt" value="true" />
</login-module>
</authentication>
</security-domain>
{code}
transport:
{code:xml}
<transport name="jdbc-gssapi" socket-binding="teiid-jdbc-gssapi" protocol="teiid">
<authentication security-domain="REDHAT.COM" type="GSS" />
<ssl mode="enabled" ssl-protocol="TLSv1" keymanagement-algorithm="SunX509">
<keystore name="/opt/jboss-eap/standalone/jboss.keystore" password="xxxxxx" key-alias="teiid.host.dev.eng.pek2.redhat.com"/>
</ssl>
</transport>
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Anu Saji updated TEIID-5311:
----------------------------
Attachment: eniqpreparser_v4.zip
> Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector, Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.x
>
> Attachments: eniqpreparser_v4.zip
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Anu Saji updated TEIID-5311:
----------------------------
Attachment: (was: eniqpreparser_v4.zip)
> Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector, Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.x
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicitl Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Anu Saji updated TEIID-5311:
----------------------------
Summary: Sybase implicitl Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison (was: Sybase implicitly Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison)
> Sybase implicitl Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector, Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.x
>
> Attachments: eniqpreparser_v4.zip
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Anu Saji updated TEIID-5311:
----------------------------
Summary: Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison (was: Sybase implicitl Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison)
> Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector, Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.x
>
> Attachments: eniqpreparser_v4.zip
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicitly Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Anu Saji updated TEIID-5311:
----------------------------
Attachment: eniqpreparser_v4.zip
> Sybase implicitly Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector, Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.x
>
> Attachments: eniqpreparser_v4.zip
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (TEIID-5311) Sybase implicitly Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Anu Saji (JIRA)
Anu Saji created TEIID-5311:
-------------------------------
Summary: Sybase implicitly Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
Key: TEIID-5311
URL: https://issues.jboss.org/browse/TEIID-5311
Project: Teiid
Issue Type: Enhancement
Components: JDBC Connector, Query Engine
Reporter: Anu Saji
Assignee: Steven Hawkins
Priority: Minor
Fix For: 10.x
Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
This format is not standard and this conversion is specific to Sybase.
As JDBC/Java standard, JDV implicitly converts
'yyyy-MM-dd HH:mm:ss' into a Timestamp value
'yyyy-MM-dd' into a Date value
So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
Constraint
We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months