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
We should add easy-to-use migrations to DazzleConf. These allow users to migrate their configuration options from older values as new settings are added.
In particular, migrating one's configuration should be type safe. For example, suppose I have an interface Config. I want to add a new version, so I copy the interface and create two files, ConfigV1 and Config, where Config stands in for the new version of the configuration. DazzleConf should then allow me to write a simple converter:
Detecting the configuration version could be accomplished in a few ways. We could simply attempt to read the configuration according to ConfigV1's definition, and if that fails, move on to the new version, Config. We could perform a differential calculation on the new definition versus the old definition, then use the unique aspects of each version for its detection, starting with newer versions as a fast-path. Or, less appealingly, developers might supply a configuration version as part of the config definition which is supposed to remain untouched by the end user.
This whole framework could even allow us to import from other configuration frameworks. For instance, maybe you wrote an encapsulation-destroying mess of public final fields whose values are loaded via reflection by a different configuration library. You'd still need to depend on the old library for deserializing the old instance, but at least you gain the benefits of DazzleConf going forward, and can stop depending on the old library eventually once end users have migrated.
The text was updated successfully, but these errors were encountered:
We should add easy-to-use migrations to DazzleConf. These allow users to migrate their configuration options from older values as new settings are added.
In particular, migrating one's configuration should be type safe. For example, suppose I have an interface
Config
. I want to add a new version, so I copy the interface and create two files,ConfigV1
andConfig
, whereConfig
stands in for the new version of the configuration. DazzleConf should then allow me to write a simple converter:Detecting the configuration version could be accomplished in a few ways. We could simply attempt to read the configuration according to ConfigV1's definition, and if that fails, move on to the new version, Config. We could perform a differential calculation on the new definition versus the old definition, then use the unique aspects of each version for its detection, starting with newer versions as a fast-path. Or, less appealingly, developers might supply a configuration version as part of the config definition which is supposed to remain untouched by the end user.
This whole framework could even allow us to import from other configuration frameworks. For instance, maybe you wrote an encapsulation-destroying mess of public final fields whose values are loaded via reflection by a different configuration library. You'd still need to depend on the old library for deserializing the old instance, but at least you gain the benefits of DazzleConf going forward, and can stop depending on the old library eventually once end users have migrated.
The text was updated successfully, but these errors were encountered: