[
https://issues.apache.org/jira/browse/NIFI-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413624#comment-15413624
]
Matt Burgess edited comment on NIFI-2518 at 8/9/16 3:03 PM:
------------------------------------------------------------
I should mention that java.sql.Time.toString() removes fractional seconds, so
this is a problem for Time types too. It appears that many databases
(PostgreSQL, MySQL, SQLServer) support HH:MM:SS.sss literals, so the
milliseconds should be kept in state too. Oracle doesn't have a "time" type per
se (DATE and TIMESTAMP instead).
was (Author: mattyb149):
I should mention that java.sql.Time.toString() removes fractional seconds, so
this is a problem for Time types too. Rather than storing a string time
"HH:MM:SS", e.g., for Time types a long milliseconds-since-epoch will be more
precise.
> AbstractDatabaseFetchProcessor Time/Timestamp Precision can causes perpetual
> reads
> ----------------------------------------------------------------------------------
>
> Key: NIFI-2518
> URL: https://issues.apache.org/jira/browse/NIFI-2518
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.0.0, 0.7.0
> Reporter: Jeremy Dyer
> Assignee: Matt Burgess
>
> The AbstractDatabaseFetchProcessor.java component has a toString method in
> the return of input database timestamps. In that, if the precision is stored
> lower than milliseconds, it can cause fetch issues. So, in the
> QueryDatabaseTable processor for example, the incremental fetch when the
> precision is at TimeStamp(6) versus TimeStamp(3) will lead to perpetual
> reads. A potential work around is for the source database to either refrain
> from using precision beyond TS(3) or to leverage a view for NiFi to consume
> from.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
