Skip to content

NIFI-6822: Ensure that when we manage a Map of ID -> Count, that we p…#3853

Merged
markap14 merged 1 commit intoapache:masterfrom
markap14:NIFI-6822
Jan 6, 2020
Merged

NIFI-6822: Ensure that when we manage a Map of ID -> Count, that we p…#3853
markap14 merged 1 commit intoapache:masterfrom
markap14:NIFI-6822

Conversation

@markap14
Copy link
Contributor

…roperly merge those maps during a checkpoint instead of overwriting existing values

Thank you for submitting a contribution to Apache NiFi.

Please provide a short description of the PR here:

Description of PR

Enables X functionality; fixes bug NIFI-YYYY.

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 master)?

  • 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:

  • Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
  • Have you written or updated unit tests to verify your changes?
  • Have you verified that the full build is successful on both JDK 8 and JDK 11?
  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
  • If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
  • If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

  • Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

combined.putAll(first);
combined.putAll(second);
final Map<String, Long> combined = new HashMap<>(first);
second.forEach((key, value) -> combined.merge(key, value, (v1, v2) -> v1 + v2));
Copy link
Contributor

@phrocker phrocker Oct 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this not be expressed a little more succinctly as second.forEach(combined.putIfAbsent) ? Same relative outcome no? I am glancing quickly so ignore me if I'm crazy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe so. putIfAbsent would say "If not there, add it. If there, leave the destination it alone." merge says "If not there, add it. If there, combine the value from both maps." So the result is different if both maps have the key.

Copy link
Contributor

@phrocker phrocker Jan 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In retrospect after a nice refreshing break I'm not sure how I arrived at such a question.

}

private <K, V> void mergeMaps(final Map<K, V> destination, final Map<K, V> toMerge, final BiFunction<? super V, ? super V, ? extends V> merger) {
if (toMerge == null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a safety could you add a null check for destination too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure that null check against destination makes sense in the way this is being used. If toMerge is null, we can simply do nothing, because there is nothing to merge. But if the destination is null, we should not return without merging the values that are expected to be merged. It makes more sense IMO to throw a NPE in such a case. Is also worth noting that currently, all objects that could be passed in for destination are guaranteed non-null and if that were to change, the existing unit tests would fail.

final V value = entry.getValue();

final V destinationValue = destination.get(key);
if (destinationValue == null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this simply be a foreach -> merge with a biconsumer accepting the original bi consumer? Might shorten the code..but again my ten thousand foot overview look might be totally off base.

Copy link
Contributor

@phrocker phrocker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the changes are good at a high level. I won't merge and leave it up to you whether my comments are something to address. Happy to merge if you feel they are non issues.

…roperly merge those maps during a checkpoint instead of overwriting existing values
@markap14
Copy link
Contributor Author

markap14 commented Jan 6, 2020

Rebased against master. Thanks for reviewing & approving @phrocker

@markap14 markap14 merged commit e4bdc79 into apache:master Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants