+1 to Andy's answer. Note that DBCPConnectionPool isn't a connection
but a connection pool, which keeps some number of connections
available for use by multiple consumers (processors, e.g.). I wouldn't
want to have to keep track of X number of configurations in a single
controller service, which would result in X connection pools, each
times Y max connections. Also with
Pierre and I talked about an attempt to support this "hot-swap"
behavior in the following way (the names should be changed, just
trying to be overly obvious with their purpose):
- Add a DelegatingDBCPService interface, extending DBCPService but
adding a method getConnectionFromPoolByName(String name).
- An implementation would probably offer user-defined properties whose
keys are names and whose values are other DBCPConnectionPool instances
- A supporting processor would have to check if the DBCPService is a
- In that case, the processor could provide a name from a flow file
attribute or something to getConnectionFromPoolByName
To avoid the code smell in the third point, there could be "hot-swap"
versions of the processors, but that doubles the number of them.
Perhaps we'd want to pick and choose, such as only ExecuteSQL and
PutSQL (as it would make downstream handling of QueryDatabaseTable and
GenerateTableFetch pretty messy).
Alternatively, we could offer in the dropdown for DBCPService
instances an option for "Use dbcp.name attribute", but there can be
name clashes all over the place in NiFi, so it'd likely have to be
"Use dbcp.id attribute" and still you'd need to know how to map your
incoming parameters/attributes (URL, DB, intended destination, e.g.)
to the IDs of the DBCP instances.