Figure out normalization for ConfigDiffer

Created on 19 April 2018, over 6 years ago
Updated 6 February 2024, 11 months ago

Problem/Motivation

On #2959072: Normalization should not strip uuid on deeper configuration levels β†’ , there was some discussion about several aspects of the normalization process that is used to pre-process configuration arrays from active and module-provided sources, before they are compared to see if they are the same, or before doing a diff so a site builder can look at the differences. This is done in the ConfigDiffer class.

The process currently does the following:

a) Strips _core and uuid components from configuration at the top level (before the parent issue, we used to strip these from all levels of configuration, but that was incorrect). I think everyone agrees this is a good idea.

b) Alphabetizes the array keys at all levels of the array. There is some question as to whether this is a good idea or not. The reason it is being done is that if config schema changes, sometimes the order of export of config changes, but the order of config keys normally doesn't affect the configuration system in a meaningful way. But it's possible it could be meaningful for some uses of configuration.

c) Removes empty arrays at all levels of the array. For instance, if your configuration looked like this:

a: 1
b: {}
c:
  - one
  - two
  - {}
  - four
d: something

we would currently be removing both the 3rd element under c (retaining the numeric array keys however), and the be element. The removal of the b element could avoid false differences being reported in some cases, such as b being added to the config schema later than the original import. But some uses of configuration might treat a key being missing and being an empty array as two different things, and removing an empty array from a sequence is probably not a good thing.

Proposed resolution

Figure out if we should change normalization. Possibly make it configurable?

Remaining tasks

Figure it out and make a patch, with tests.

User interface changes

If normalization is changed, reports will have either more or fewer reports of changed configuration.

API changes

No.

Data model changes

No.

πŸ“Œ Task
Status

Active

Version

2.0

Component

Base module

Created by

πŸ‡ΊπŸ‡ΈUnited States jhodgdon Spokane, WA, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024