Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1407#discussion_r96434505
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
---
@@ -115,20 +128,36 @@ public GenerateTableFetch() {
@OnScheduled
public void setup(final ProcessContext context) {
+ // The processor is invalid if there is an incoming connection and
max-value columns are defined
+ if (context.getProperty(MAX_VALUE_COLUMN_NAMES).isSet() &&
context.hasIncomingConnection()) {
+ throw new ProcessException("If an incoming connection is
supplied, no max-value column names may be specified");
--- End diff --
For backwards-compatibility, what do you think about only falling back to
the column name as the key if the table name property does not contain
Expression Language? I'm thinking the only use case we should have to support
from before is if the table name is static (as it was required to be before
now). This would not allow for incoming flow files to specify via attribute the
same table name as before, but I don't see that being a high-priority use case
necessarily. With this approach, currently configured processors would continue
to work as-is, but once you change to incoming flow files (or use EL), the new
scheme would apply. Even currently configured processors would automatically
switch to the new scheme as soon as a new maximum value is observed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
