Hypothetically, I think the path of least resistance might be to refactor the readers and writers to allow custom properties like "timestamp.format.1...N" and have those properties evaluated until one is found that can parse the incoming text. Thoughts?
On Wed, Aug 14, 2019 at 12:34 PM Peter Wicks (pwicks) <pwi...@micron.com> wrote: > Not that I’m aware of. We implemented something custom that lets you > specify it with attributes on the FlowFile (something like > data.field.#.format=….), we do the same thing for binary/hex fields. But we > didn’t contribute it as it’s part of a custom record processing processor > that’s application specific. > > > > Thanks, > > Peter > > > > *From:* Mike Thomsen <mikerthom...@gmail.com> > *Sent:* Wednesday, August 14, 2019 8:35 AM > *To:* users@nifi.apache.org > *Subject:* [EXT] Specifying formatters at a record field level > > > > If there any way to specify a timestamp format string on each field that > is a TIMESTAMP (long, logical type timestamp-millis)? We have a case where > we would need at least three, possibly half a dozen timestamp formats to > read a record set. > > > > Thanks, > > > > Mike >
