Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (4 by maintainers)

github_iconTop GitHub Comments

jniochecommented, Jul 11, 2018

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

jcruzmartinicommented, Jul 11, 2018

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Hibernate 5 Naming Strategy Configuration - Baeldung
Hibernate uses the Physical Naming Strategy to map our logical names to a SQL table and its columns. By default, the physical name...
Read more >
Jackson Property Custom Naming Strategy - DZone
The robust implementation of Jackson allows adding a custom property naming strategy, which can be helpful in such cases. import
Read more >
Hibernate field naming issue with Spring Boot (naming strategy)
SINCE SPRING-BOOT 1.4. Starting from 1.4, because of the switch to Hibernate 5, the naming strategy has been updated to SpringPhysicalNamingStrategy which ...
Read more >
Gson Builder — Basics & Naming Policies - Future Studio
Custom Field Naming. The provided policies in combination with the @SerializedName might not be enough to cover your use case. You can implement...
Read more >
Naming Strategies in Hibernate 5 - Thorben Janssen
Hibernate's naming strategies define how to get the table and column names for an entity. You can implement your own mapping to fullfil...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found