https://github.com/apache/nifi/pull/2940
This is what I came up with, however not sure I covered your use case
Aldrin. I tried to have a symlink with the name /opt/nifi/nifi-current to
point to the original installation path, but the WORKDIR instruction
resolves the link and we end up running NiFi
I'll scope it out. Thanks for taking an initial effort on it!
On Wed, Aug 8, 2018 at 8:29 AM Peter Wilcsinszky
wrote:
> https://github.com/apache/nifi/pull/2940
>
> This is what I came up with, however not sure I covered your use case
> Aldrin. I tried to have a symlink with the name /opt/nifi/n
Hello all,
I recently started using nifi to read binlogs and ingest to various
sources. I noticed that when the column type is unsigned, the underlaying
library sends signed version of the value. (Eg, column type is unsigned
tinyint, when the inserted value is 128, it sends -128). Its related to
h
Looks like they've identified the onus being on the client not the
library. We do read column types when a Distributed Map Cache Client
is specified, so we should probably be able to do these conversions.
Please feel free to write a Jira [1] to cover this.
Thanks,
Matt
[1] https://issues.apache.o
I’m seeing
https://github.com/apache/nifi/blob/master/nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/RecordReader.java#L34
being quoted as a reason to NOT build Record based processors but instead
stick with the original Processor api.
Yet, on list and on hipchat and in pr’s
