[
https://issues.apache.org/jira/browse/NIFI-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413555#comment-15413555
]
Matt Burgess commented on NIFI-2518:
------------------------------------
The JDBC spec says that toString() must return fractional seconds up to
nanoseconds (if available). I believe the issue here is not with toString() but
with a line that calls getTime(), which removes micro- and nano-seconds, then
stores a timestamp from that. Looks like it might've been a copy-paste error
from the Oracle logic (which should remain unless an improvement Jira is filed
separately to handle the user's database's default timestamp literal, e.g.)
If the Timestamp from resultSet.getTimestamp() is used rather than calling
getTime(), the value should be stored/retrieved correctly.
> AbstractDatabaseFetchProcessor 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)
