[
https://issues.apache.org/jira/browse/NIFI-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447422#comment-16447422
]
ASF subversion and git services commented on NIFI-5082:
-------------------------------------------------------
Commit ba32879ec81cdfa3c44734ab8b210b13fa0581ac in nifi's branch
refs/heads/master from [~ca9mbu]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=ba32879 ]
NIFI-5082: Added support for custom Oracle timestamp types to Avro conversion
This closes #2638
Signed-off-by: Mike Thomsen <mikerthom...@gmail.com>
> SQL processors do not handle Avro conversion of Oracle timestamps correctly
> ---------------------------------------------------------------------------
>
> Key: NIFI-5082
> URL: https://issues.apache.org/jira/browse/NIFI-5082
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Matt Burgess
> Assignee: Matt Burgess
> Priority: Major
>
> In JdbcCommon (used by such processors as ExecuteSQL and QueryDatabaseTable),
> if a ResultSet column is not a CLOB or BLOB, its value is retrieved using
> getObject(), then further processing is done based on the SQL type and/or the
> Java class of the value.
> However, in Oracle when getObject() is called on a Timestamp column, it
> returns an Oracle-specific TIMESTAMP class which does not inherit from
> java.sql.Timestamp or java.sql.Date. Thus the processing "falls through" and
> its value is attempted to be inserted as a string, which violates the Avro
> schema (which correctly recognized it as a long of timestamp logical type).
> At least for Oracle, the right way to process a Timestamp column is to call
> getTimestamp() rather than getObject(), the former returns a
> java.sql.Timestamp object which would correctly be processed by the current
> code. I would hope that all drivers would support this but we would want to
> test on (at least) MySQL, Oracle, and PostgreSQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
