Fix Version/s: None
Team:Data Access and Database
The present design of the Configuration service is quite complex. There are 5 classes (and a few hundred methods) in the core of the service:
The second issue is a distributed state of the transient configuration that's spread in between static data members of class Configuration and member data of class ConfigurationBase.
The third issue is related to how the default values of the parameters are stored and used. In the present implementation there are ~50 static members of class ConfigurationBase representing the defaults. The defaults are separate from the target variables (where the current state of the corresponding configuration parameters are stored).
All together, this makes it quite cumbersome to add new configuration parameters, or modify existing ones.
There is also a new requirement in the Replication/Ingest system that would be hard to address within the present paradigm of the service - serializing the state of the configuration and sending it over-the-wire protocol from the Master Controller to the Replication/Ingest workers.
The proposal is modeled after a similar effort made in a context of
To address the above stated issues, the following refactoring is proposed:
- Flatten the hierarchy of the existing classes into a single class Configuration.
- Keep the named methods as they are now to avoid modifying the dependent code.
- Implement the transient state as a single object of class nlohmann::json::object.
- Set defaults as initial value of the transient object. The defaults will be amended when the corresponding "external" source of the configuration will be used to set up the new state.
- Implements a few forms of the configuration construction from the following sources:
- MySQL (will require a connection string mysql://<user>:<password>@<host>:<port>/<database>).
- Transient JSON object.
- A JSON-formatted text file.
This approach will benefit from the existing features of the nlohmann::json library, such as: serialization/de-serialization into/from a string, json path capability.
Besides, the new implementation of the service won't affect existing code relying upon the configuration. Existing unit tests should also work. Though, they will need to be migrated from relying upon the "key-values" maps for setting the tested object state to use a transient JSON object.