Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
wish: Expose some fields on StatusUpdaterBolt to allow custom naming strategy implementation #591
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.
Our main issue basically consist in the limited scope of all variables in StatusUpdaterBolt that we need to interact in
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.
changed the title from
question / wish : Expose some fields on StatusUpdaterBolt to allow custom naming strategy implementation
Expose some fields on StatusUpdaterBolt to allow custom naming strategy implementation
Jul 10, 2018
What do you think? I can see a benefit of doing this for cases where we want to keep a separate index per language for instance.
I am not against setting the fields to protected but I am not convinced that it is necessary for all of them. Also, I wouldn't want the subclass to be able to change the values and would prefer getters.
@xytian315 would the solution above work for you as well?
Would either of you like to submit a PR?
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.