[
https://issues.apache.org/jira/browse/NIFI-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440950#comment-16440950
]
ASF GitHub Bot commented on NIFI-5082:
--------------------------------------
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2638#discussion_r182100896
--- Diff:
nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/record/ResultSetRecordSet.java
---
@@ -350,6 +350,8 @@ private static RecordFieldType getFieldType(final int
sqlType) {
return RecordFieldType.TIME;
case Types.TIMESTAMP:
case Types.TIMESTAMP_WITH_TIMEZONE:
+ case -101: // Oracle's TIMESTAMP WITH TIME ZONE
--- End diff --
@markap14 I don't think we need these cases (Calcite would never return
Oracle types, and there'd be no other way to generate them?) but put them in
just in case (as this does Java SQL Timestamp handling). If you agree then I
can remove this (although it's likely no-harm-no-foul)
> 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)
