Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2973#discussion_r213905074
--- Diff:
nifi-nar-bundles/nifi-extension-utils/nifi-reporting-utils/src/main/java/org/apache/nifi/reporting/util/provenance/ProvenanceEventConsumer.java
---
@@ -241,20 +255,24 @@ private long updateLastEventId(final
List<ProvenanceEventRecord> events, final S
private boolean isFilteringEnabled() {
return componentTypeRegex != null || !eventTypes.isEmpty() ||
!componentIds.isEmpty()
- || componentTypeRegexExclude != null ||
!eventTypesExclude.isEmpty() || !componentIdsExclude.isEmpty();
+ || componentTypeRegexExclude != null ||
!eventTypesExclude.isEmpty() || !componentIdsExclude.isEmpty()
+ || componentNameRegex != null || componentNameRegexExclude
!= null;
--- End diff --
In general, I don't push changing "traditional" code blocks to "new" style
just for the sake of it, but in this case, I think a Java 8-style `.stream()`
construction will make this clearer (some of these fields are `List` and some
are `Pattern`, and the `Pattern` can be empty/blank (which is not checked
here), which would not (logically) enable filtering.
I made two commits ([a regression test on the current
logic](https://github.com/alopresto/nifi/commit/0e717001a6124d6863f21efd18130ba996513e77)
and [a new
implementation](https://github.com/alopresto/nifi/commit/f586dd4f7cf1b0ab33c77e7053028a758ca057d1))
and it still works. Personally, I think this form is clearer and will scale
more gracefully if new properties are added. Let me know your thoughts.
---
