+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 DelegatingDBCPService (yuck) - 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. Thoughts? Thanks, Matt
