You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Matt Burgess (JIRA)" <ji...@apache.org> on 2018/04/13 22:41:00 UTC

[jira] [Assigned] (NIFI-5082) SQL processors do not handle Avro conversion of Oracle timestamps correctly

     [ https://issues.apache.org/jira/browse/NIFI-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Burgess reassigned NIFI-5082:
----------------------------------

    Assignee: Matt Burgess

> 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)