custom log levels in HigherOrderOperation's `refreshAllLocations` method.

refreshAllLocations by default logs at info and warn levels which is too noisy for our usecase. I believe that there is a case to allow customization of this behavior.

The CatalogBuilder, provides the logger used by the DatabaseEntitiesCatalog and the HigherOrderOperations instance, when creating them. The logger logs to our standard application’s stdout that is picked up by our logging daemons for our service logs.

As refreshAllLocations, we cannot disable or provide a dummy logger to the builder as that would mean we lose the error/warning logs on entities operations as well.

Feature Suggestion

We can solve this in 2 ways.

1. Reduce the log levels in the refreshAllLocations to debug and info or simply debug.
2. Allow the instantiation to customize the log levels.

I think option 2 is better , because it allows users to define how important these logs are for their respective purposes.

Possible Implementation

The builder can optionally provide methods to set the logging levels for each of the Catalog (Entities, Locations, higherOrderOperations) that users can then use to customize the logging levels. It can also have a default log level that it can use, in case the user doesn’t wish to supply one.

An example method would be something along the lines of :

setLoggingLevel(entitiesCatalog, logLevel) or setStandardLogLevel(entitiesCatalog, logLevel) and setErrorLogLevel(entitiesCatalogLevel, logLevel)or asetLogger(enum.entitiesCatalog, logger)`

Context

We are using the HigherOrderOperation class to track and update roughly 15,000+ entries. We are planning to add more entries in our system and this method currently is convenient to keep track of our existing catalog sources.

However, the presence of such a large catalog of items, is making it very hard to debug requests and issues via our logs. We run the refreshAllLocations for all the entries once a day and the class emits out approx. 3 log lines per entity. During the period of time when it updates the data, roughly 45,000 lines of logs are emitted ,alongside othe request and metrics logging. This makes sifting through the logs a burdensome task and we would like the ability to customize this behaviour.

[GoWind]

sounds like a good implementation idea. I will raise a PR with a child logger that can then be filtered out.

[benjdlambert]

This seems to be fixed now, reopen if not 👍