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

Matt Burgess commented on NIFI-5121:
------------------------------------

I have a PR forthcoming where I took a different approach to the API change, 
instead of making getConnection() a default impl (since all existing impls have 
a body for this method), I made getConnection(Map) a default method for calling 
getConnection(). That maintains existing behavior with the caveat that if 
you're going to override getConnection(Map), you'll want to override 
getConnection() to return getConnection(Collections.emptyMap()). This is 
indicated in the javadoc.

Also I changed all calls to getConnection() to getConnection(Map), passing in 
flow file attributes where available. Note that for processors that handle 
multiple flow files in a single execution, attributes will only be passed to 
the method when there is a single flow file in the "batch".

> 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
>    Affects Versions: 1.6.0
>            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)

Reply via email to