[
https://issues.apache.org/jira/browse/NIFI-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422018#comment-15422018
]
ASF GitHub Bot commented on NIFI-2576:
--------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/869
@patricker thanks for the contribution! Definitely makes sense to support
both formats...
What do you think about using a regex to determine if it is a long, and if
so then parseLong, otherwise attempt to parse a date? (could be the other way
around, but I was thinking the regex for a long is easiest)
I'm thinking of the case where someone is always sending in longs and it is
continuously throwing/catching the parse exception, that may end up being
expensive.
> PutSQL assumes all Timestamps are provided in Epoch
> ---------------------------------------------------
>
> Key: NIFI-2576
> URL: https://issues.apache.org/jira/browse/NIFI-2576
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.0.0
> Reporter: Peter Wicks
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When PutSQL sees a TIMESTAMP data type it assumes that it's being provided as
> a Long in Epoch format.
> This doesn't make much sense since the Query Database tools that return Avro
> return timestamps as strings; and thus following the Avro->JSON->JSON To SQL
> Route leads to timestamps as being strings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
