Thanks Dan. The blogs encourage us to keep building.
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Sep 5, 2018, at 4:25 PM, dan young wrote:
>
> Heya Andy,
>
> yes, that seems legit...we'll make it work on
Heya Andy,
yes, that seems legit...we'll make it work on our side...
Keep up the awesome work on NiFi, powers all of our ETL here now :)
Dano
On Wed, Sep 5, 2018 at 5:14 PM Andy LoPresto wrote:
> Dan,
>
> Does the proposal I submitted meet your requirements?
>
> Andy LoPresto
> alopre...@apac
Dan,
Does the proposal I submitted meet your requirements?
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Sep 5, 2018, at 4:09 PM, dan young wrote:
>
> We're using it as well, in the same/similar fashion as
We're using it as well, in the same/similar fashion as being discussed in
the thread...
Dano
On Wed, Sep 5, 2018, 10:07 AM Brandon DeVries wrote:
> Andy,
>
> We use it pretty much how Joe is... to create a unique composite key. It
> seems as though that shouldn't be a difficult functionality t
Joe and Brandon,
Thanks for your input here. I agree that changing the behavior of an existing
processor (that is used in people’s flows) is a breaking change and probably
requires a major release, which is why I didn’t do that in the PRs. As written
today, they are fully backward-compatible. M
I vote to keep for backward compatibility.
On Wed, 5 Sep 2018 at 13:33 Brandon DeVries wrote:
> Mike,
>
> We don't use it with Elasticsearch.
>
> Fundamentally, it feels like the problem is that this change would break
> backwards compatibility, which would require a major version bump. So, in
Mike,
We don't use it with Elasticsearch.
Fundamentally, it feels like the problem is that this change would break
backwards compatibility, which would require a major version bump. So, in
lieu of that, the options are probably 1) use a different name or 2) put
the new functionality in HashConte
Brandon,
What processor do you use it for in that capacity? If it's an ElasticSearch
one we can look into ways to bring this functionality into that bundle so
Andy can refactor.
Thanks,
Mike
On Wed, Sep 5, 2018 at 12:07 PM Brandon DeVries wrote:
> Andy,
>
> We use it pretty much how Joe is...
Andy,
We use it pretty much how Joe is... to create a unique composite key. It
seems as though that shouldn't be a difficult functionality to add.
Possibly, you could flip your current dynamic key/value properties. Make
the key the name of the attribute you want to create, and the value is the
a
Hey Andy,
We're currently using the HashAttribute processor. The use-case is that we
have various events that come in but sometimes those events are just
updates of previous ones. We store everything in ElasticSearch. So for
certain events, we'll calculate a hash based on a couple of attributes in
I opened PRs for 2980 [1] and 2983 [2] which add more performant, consistent,
and full-featured processors to calculate cryptographic hashes of flowfile
content and flowfile attributes. I would like to deprecate and drop support for
HashAttribute, as it performs a convoluted calculation that was
11 matches
Mail list logo
