[ https://issues.apache.org/jira/browse/NIFI-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437506#comment-16437506 ]
Matt Burgess commented on NIFI-5082: ------------------------------------ I propose we check the SQL type for TIMESTAMP (93), and if that is the case, we use getTimestamp() rather than getObject() to put into the "value" variable for further processing. > 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 > 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)