[jira] [Commented] (NIFI-5121) DBCPService should support passing in an attribute map when obtaining a connection

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471819#comment-16471819 ] 

ASF subversion and git services commented on NIFI-5121:
-------------------------------------------------------

Commit 099bfcdf3a5873a311312eb7e9e85b7b22ef1b98 in nifi's branch refs/heads/master from [~ca9mbu]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=099bfcd ]

NIFI-5121: Added DBCPService API method for passing in flow file attributes when available

This closes #2658

Signed-off-by: Mike Thomsen <mi...@gmail.com>


> DBCPService should support passing in an attribute map when obtaining a connection
> ----------------------------------------------------------------------------------
>
>                 Key: NIFI-5121
>                 URL: https://issues.apache.org/jira/browse/NIFI-5121
>             Project: Apache NiFi
>          Issue Type: Improvement
>            Reporter: Bryan Bende
>            Assignee: Matt Burgess
>            Priority: Minor
>
> Many users have asked for a way to obtain dynamic database connections. Essentially being able to use the existing SQL processors like PutSQL, etc, and be able to pass in flow file attributes to the DBCPService to obtain a connection based on the attributes.
> The current DBCPService interface has a single method:
> {code:java}
> Connection getConnection(){code}
> Since there is no way for a processor to pass in any information, we can add an additional method to this interface and make the interface like this:
> {code:java}
> Connection getConnection(Map<String,String> attributes)
> default Connection getConnection() {
>   return getConnection(Collections.emptyMap());
> }{code}
> This would leave it up to the implementations of DBCPService interface to decide if they want to use the attributes map for anything.
> The DBCPConnectionPool would not use the attributes map and would continue to provide a fixed connection pool against a single data source.
> A new implementation can then be created that somehow maintains multiple connection pools, or creates connections on the fly.
> The PropertyDescriptors in each implementation should indicate how they use expression language.
> For example, since DBCPConnectionPool will not use the attribute map, it's property descriptors will indicate expression language scope as variable registry only:
> {code:java}
> .expressionLanguageSupported(ExpressionLanguageScope.VARIABLE_REGISTRY){code}
> The dynamic implementations should indicate:
> {code:java}
> .expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBURES){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)