Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1407#discussion_r98810570
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/QueryDatabaseTable.java
---
@@ -212,9 +215,21 @@ public void onTrigger(final ProcessContext context,
final ProcessSessionFactory
final Map<String, String> statePropertyMap = new
HashMap<>(stateMap.toMap());
//If an initial max value for column(s) has been specified using
properties, and this column is not in the state manager, sync them to the state
property map
- for(final Map.Entry<String,String> maxProp :
maxValueProperties.entrySet()){
- if
(!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
- statePropertyMap.put(maxProp.getKey().toLowerCase(),
maxProp.getValue());
+ for (final Map.Entry<String, String> maxProp :
maxValueProperties.entrySet()) {
+ String maxPropKey = maxProp.getKey().toLowerCase();
+ String fullyQualifiedMaxPropKey = getStateKey(tableName,
maxPropKey);
+ if (!statePropertyMap.containsKey(fullyQualifiedMaxPropKey)) {
+ String newMaxPropValue;
+ // If we can't find the value at the fully-qualified key
name, it is possible (under a previous scheme)
+ // the value has been stored under a key that is only the
column name. Fall back to check the column name,
+ // but store the new initial max value under the
fully-qualified key.
+ if (statePropertyMap.containsKey(maxPropKey)) {
+ newMaxPropValue = statePropertyMap.get(maxPropKey);
+ } else {
+ newMaxPropValue = maxProp.getValue();
--- End diff --
I was suggesting that for QueryDatabaseTable and Initial max value, instead
of GenerateTableFetch. Because not being able to know the column type seemed an
obstacle to support incoming Flow Files in QueryDatabaseTable ([PR
comment](https://github.com/apache/nifi/pull/1407#issuecomment-274592165) and
[JIRA
comment](https://issues.apache.org/jira/browse/NIFI-2881?focusedCommentId=15811850&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15811850)).
However, I agree with you that, as you've written, since GenerateTableFetch
and ExecuteSQL can be used if user need to pass arguments from incoming flow
files, it's not necessary to support incoming flow files in QueryDatabaseTable.
If we are not going to add incoming flow file support for
QueryDatabaseTable in this PR, maybe we should add some docs in
QueryDatabaseTable capability description to guide users to refer
GenerateTableFetch and ExecuteSQL, too.
---
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.
---
