Problem/Motivation

Calculating configuration change data is a relatively resource-intensive operation, particularly if done for a large set of configuration like the system.all report.

Proposed resolution

Store change data with the state API. Register a listener for relevant ConfigEvents to trigger updating state information.

Remaining tasks

User interface changes

API changes

Comments

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Status: Active » Closed (won't fix)

I disagree with this. The calculation doesn't take very long to run and this idea is very complicated. Besides which it wouldn't really work - the module is about telling when the default config provided by modules has been updated because you updated a module. There is no config state change that happens when this occurs.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented

Besides which, even if it could be made to work, you're asking for some overhead to be added to *every* config change event, to prepare for the cost of running this report, which would presumably be a relatively rare event. It just doesn't seem practical, seems very complicated to get work, probably won't work, and would slow down all operations on the site in order to save time on something that really isn't all that time consuming in the first place and is rarely done.

If you have a site where the 'all' report takes too long, run a subset.