server icon indicating copy to clipboard operation
server copied to clipboard

feat(lexicon): migrate config key/value

Open ArtificialOwl opened this issue 8 months ago • 3 comments

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

ArtificialOwl avatar May 14 '25 18:05 ArtificialOwl

:x: We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format.

codecov[bot] avatar May 15 '25 10:05 codecov[bot]

@nickvergessen @susnux

what you are looking for is:

	new ConfigLexiconEntry('new_key', ValueType::BOOL, rename: 'old_key', options: ConfigLexiconEntry::RENAME_INVERT_BOOLEAN),

ArtificialOwl avatar May 15 '25 16:05 ArtificialOwl

unrelated test issues

ArtificialOwl avatar Jun 13 '25 16:06 ArtificialOwl

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

ArtificialOwl avatar Jun 24 '25 10:06 ArtificialOwl

You are right, but it makes the problem worse and I feel like there will be no improvement later if we ignore it now.

provokateurin avatar Jun 24 '25 10:06 provokateurin

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:

  • AppConfig was made before the ability to use Enums,
  • sensitivity is not set as a type bit anymore in UserConfig,
  • cache also includes the userId dimension,

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.

ArtificialOwl avatar Jun 24 '25 11:06 ArtificialOwl