[
https://issues.apache.org/jira/browse/NIFI-12703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-12703.
-----------------------------------
Resolution: Feedback Received
Apache NiFi 1.x is no longer maintained and no new release is planned on the
1.x release line. Marking as resolved as part of a cleanup operation. Please
open a new one with an updated description if this is still relevant for NiFi
2.x.
> LookupRecord against Elasticsearch creates MapRecord string on 2nd lookup
> --------------------------------------------------------------------------
>
> Key: NIFI-12703
> URL: https://issues.apache.org/jira/browse/NIFI-12703
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.24.0
> Environment: Tried in both Docker and RedHat 8. Uses Elasticsearch 8.
> Reporter: Stephen Jeffrey Hindmarch
> Priority: Minor
> Attachments: screenshot-1.png
>
>
> What Happens: When using 2 different record lookups in series against a
> single Elasticsearch lookup service, the second lookup will add the returned
> data as a MapRecord string instead of a JSON sub-record.
> What I Expect: The lookup results should be written into the record as a JSON
> sub-record.
> How To Reproduce:
> In this scenario I am trying to enrich some records from data stored in an
> Elasticsearch database. This uses an ElasticsearchLookupService, and JSON
> readers and writers with default settings. No schemas are used.
> For example the data set might be
> {noformat}
> [
> {"key":"two","value":2},
> {"key":"four","value":4}
> ]{noformat}
> My use case is that my data has two possible key fields to use to enrich
> against one data set. I want to try enriching against one field, and if that
> fails try the second set.
> For example the input data might be
> {noformat}
> [
> {"name":"bob","role":"user","hands":"two","Enrichment":{}},
> {"name":"bill","role":"dog","legs":"four","Enrichment":{}}
> ]{noformat}
> I run a lookup with a LookupRecord processor using one of the fields. For
> data which matches this data is updated correctly in the record as a JSON
> sub-record.
> For example, if the first processor uses the "hands" field for the lookup, to
> result is as follows
> {noformat}
> [
> {"name":"bob","role":"user","hands":"two",
> "Enrichment":{"limbs":{"key":"two","value":2}},
> "legs":null}
> ]{noformat}
> The data that did not match is now passed through a second LookupRecord
> processor, this time using the alternative key. This time the returned data
> is incorrectly written into the flow as a MapRecord string. For example, if
> the second processor uses the "legs" field for the lookup, the result is as
> follows.
> {noformat}
> [
> {"name":"bill","role":"dog","hands":null,
> "Enrichment":{"limbs":"MapRecord[{key=four, value=4}]"},
> "legs":"four"}
> ]{noformat}
> It does not matter which order the enrichment lookups are tried, it is always
> the second processor which produces the MapRecord string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
