wish: Expose some fields on StatusUpdaterBolt to allow custom naming strategy implementation

Hi @jnioche , we are working with ES integration of the crawler and for some reasons we want to extend the functionality of StatusUpdaterBolt , basically we want to apply our custom naming strategy for handling many status indexes and content indexes names in parallel. Names will depend on same information stored previously in metadata. eg. status_${some_property_name}. The existing code fits perfect to our needs, so we want to extend existing class and only override behavior that you have on store method.

Our main issue basically consist in the limited scope of all variables in StatusUpdaterBolt that we need to interact in store method of our child class that will be extending StatusUpdaterBolt.

Having those vars as protected or having getters for those will allow to extend this class and allow custom implementations in a future.

Obviously, we can implement our whole custom implementation extending AbstractStatusUpdaterBolt, but just want to check if you want to avoid overriding of this class for any special reason.

Thanks for your time in advance.

[jnioche]

Except that it can’t be based on Metadata values in the spouts. I’d create a constructor for the AbstractSpout where you can specify a non-default index name, similar to what I did for the IndexerBolt

[jcruzmartini]

Thanks @jnioche for your quick response, your proposal sounds great. I am gonna be creating a pull request for including those changes. I am thinking that probably we will need to do same in AbstractSpout class for getting custom indexName when executing ES query in AggregationSpout. I am gonna talk with @xytian315 in order to coordinate modifications required for both changes.