-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[suggestion] Separate "user" config from "resolved" config #3500
Comments
In code we need only two structs: Also I would consider making the |
There's a better way to do it. The config itself is meaningless. What it configures is the thing for which modification makes sense. When I was dealing with #1486 and related issues, what I found was that Perhaps instead of a struct-centric approach there is a trait-based one. So each configuration parameter is its own struct. And each user of said struct has to implement methods for interpreting that information. In the terminology of @0x009922 the user config is an ephemeral immutable struct that gets constructed once for each source and consumed, while the resolved config is the value of each variable that we have for each object. I'll probably need to open a PR with a PoC to make it more clear. |
Closed by #4239 |
Feature request
It is already done with
Configuration
(i.e. resolved) andConfigurationProxy
(i.e. user) structs. The problem is that they are coupled to each other too tight, and there is not much semantic separation. Meanwhile, Iroha does have a semantic of parsing "raw" configuration and validating it.Resolved config should have different fields. For example, user config might have
public_key
andprivate_key
fields, while the resolved configuration will only have a singlekey_pair
. It might be worth to define two separate structures (user and resolved configs) if there is a large difference between fields.I propose to change naming as well, to reflect the purpose clearer:
UserConfig
instead ofConfigurationProxy
, andResolvedConfig
instead ofConfiguration
. Or something like that.Additionally, it will be helpful to print the resolved configuration (with sensitive data being sanitised) to DEBUG/TRACE level.
Motivation
The transformation from "user" to "resolved" is the great place for validation, deprecation warnings, default fallbacks, and any other custom logic.
The text was updated successfully, but these errors were encountered: