feat(lexicon): migrate config key/value
Allow a rename of config keys, with a migration of linked values also, using old config key will returns value from new config key
migration can also be initiated using:
./occ config:list --migrate [<appId>]
- [x] tests
adding to CoreConfigLexicon.php the entry:
new ConfigLexiconEntry('key123', ValueType::STRING, '', lazy: true, rename: 'key000'),
will returns:
$ ./occ config:app:get --details core key000
- app: core
- key: key123
- value: my_value_in_database
- type: string
- lazy: true
- sensitive: false
:x: We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format.
@nickvergessen @susnux
what you are looking for is:
new ConfigLexiconEntry('new_key', ValueType::BOOL, rename: 'old_key', options: ConfigLexiconEntry::RENAME_INVERT_BOOLEAN),
unrelated test issues
LGTM, but I'm a bit confused why almost all changes to AppConfig/UserConfig are duplicate. I am pretty sure, that over time the implementations will deviate more and more and this calls for painful bugs. Would it be possible to have a base class with the shared logic and have each of them inherit from it? @ArtificialOwl
Could be, but not sure it is the purpose of this PR
You are right, but it makes the problem worse and I feel like there will be no improvement later if we ignore it now.
I am all for avoiding duplicate code but, from my point of view, there is enough difference between AppConfig and UserConfig that trying to link them together will make everything more complex:
-
AppConfigwas made before the ability to use Enums, - sensitivity is not set as a type bit anymore in
UserConfig, - cache also includes the
userIddimension,
I already added ConfigManager in that PR that contains few tools used by both classes.
What we can do is having a look at the final version of the code when moving the feature from unstable/ to public/ - that I would like to request in the next 2 weeks.