New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIFI-8613: Improve FlattenJson Processor #5083
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution @naddym! The addition of the unflatten option looks useful. The changes look good in general, I noted a few a couple questions about the character set expectations and included a recommendation to adjust error logging.
|
||
flowFile = session.write(flowFile, os -> os.write(flattened.getBytes())); | ||
final StringBuilder contents = new StringBuilder(); | ||
session.read(flowFile, in -> contents.append(IOUtils.toString(in, Charset.defaultCharset()))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the previous approach relied on the system default character set when converting from byte array to string, what do you think about either making UTF-8 the standard character set, or adding a new processor property to configure the character set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, let me add new character set property to stay consistent with other processors. Thanks.
.unflatten(); | ||
} | ||
|
||
flowFile = session.write(flowFile, out -> out.write(resultedJson.getBytes())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the comment on handling input, specifying a character set on String.getBytes() would clarify the expected output as opposed to relying on the system defaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, will do.
if (returnType.equals(RETURN_TYPE_FLATTEN)) { | ||
resultedJson = new JsonFlattener(contents.toString()) | ||
.withFlattenMode(flattenMode) | ||
.withSeparator(separator.charAt(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The separator character could be declared once outside of the conditional and reused as opposed to calling separator.charAt(0)
in both conditional blocks.
|
||
session.transfer(flowFile, REL_SUCCESS); | ||
} catch (Exception ex) { | ||
} catch (Exception e) { | ||
getLogger().error("Failed to {} json due to {}", new Object[]{returnType, e}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recent updates to the logger interface now allow passing placeholder values as variable arguments. If the goal is to include the stack trace of the exception, which would be helpful, then the second placeholder should be removed from the log message string.
getLogger().error("Failed to {} json due to {}", new Object[]{returnType, e}); | |
getLogger().error("Failed to {} JSON", returnType, e); |
Thank you @exceptionfactory for the detailed review. All suggestions pointed out looks good, will work on changing them.. |
@@ -157,25 +203,36 @@ public void onTrigger(final ProcessContext context, final ProcessSession session | |||
final String mode = context.getProperty(FLATTEN_MODE).getValue(); | |||
final FlattenMode flattenMode = getFlattenMode(mode); | |||
|
|||
String separator = context.getProperty(SEPARATOR).evaluateAttributeExpressions(flowFile).getValue(); | |||
|
|||
final Character separator = context.getProperty(SEPARATOR).evaluateAttributeExpressions(flowFile).getValue().charAt(0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the updates @naddym, looks like the automated builds failed due to missing a trailing )
on this line.
final Character separator = context.getProperty(SEPARATOR).evaluateAttributeExpressions(flowFile).getValue().charAt(0; | |
final Character separator = context.getProperty(SEPARATOR).evaluateAttributeExpressions(flowFile).getValue().charAt(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, Somehow missed it while copying after test. Thanks again for commenting.
- Unflattening a flattened json - Preserving primitive arrays such as strings, numbers, booleans and null in a nested json - Logging errors when failure - Pretty printing resulted json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested flatten and unflatten operations, changes look good, thanks @naddym! +1 Merging.
- Unflattening a flattened json - Preserving primitive arrays such as strings, numbers, booleans and null in a nested json - Logging errors when failure - Pretty printing resulted json This closes apache#5083 Signed-off-by: David Handermann <exceptionfactory@apache.org>
Thank you for submitting a contribution to Apache NiFi.
Description of PR
Please provide a short description of the PR here:
Improvement to FlattenJson Processor has following changes:
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically
main
)?Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not
squash
or use--force
when pushing to allow for clean monitoring of changes.For code changes:
mvn -Pcontrib-check clean install
at the rootnifi
folder?LICENSE
file, including the mainLICENSE
file undernifi-assembly
?NOTICE
file, including the mainNOTICE
file found undernifi-assembly
?.displayName
in addition to .name (programmatic access) for each of the new properties?For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.