You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your refactoring request related to a problem? Please describe.
I'm currently in the middle of making tedge config async, and this has led me to discover that we are frequently loading configuration for every component of a process (e.g. in tedge-agent, we load the config globally, then for operations, then for restart management, etc.). I believe this is due to us needing the config_dir as well as tedge_config, so we just pass in tedge_config_location and then (rather wastefully) re-read the config.
Describe the solution you'd like TEdgeConfig could keep track of where it originated from by cloning TEdgeConfigLocation. Then when we need to access fields of TEdgeConfigLocation, we could do this via TEdgeConfig, avoiding both duplicated reads and unnecessary parameters for the functions currently performing duplicated reads.
Describe alternatives you've considered
We could just pass in the configuration directory separately to the relevant functions, however I think it makes sense to have a single source of truth.
Additional context
The text was updated successfully, but these errors were encountered:
Is your refactoring request related to a problem? Please describe.
I'm currently in the middle of making
tedge config
async, and this has led me to discover that we are frequently loading configuration for every component of a process (e.g. in tedge-agent, we load the config globally, then for operations, then for restart management, etc.). I believe this is due to us needing theconfig_dir
as well astedge_config
, so we just pass intedge_config_location
and then (rather wastefully) re-read the config.Describe the solution you'd like
TEdgeConfig
could keep track of where it originated from by cloningTEdgeConfigLocation
. Then when we need to access fields ofTEdgeConfigLocation
, we could do this viaTEdgeConfig
, avoiding both duplicated reads and unnecessary parameters for the functions currently performing duplicated reads.Describe alternatives you've considered
We could just pass in the configuration directory separately to the relevant functions, however I think it makes sense to have a single source of truth.
Additional context
The text was updated successfully, but these errors were encountered: