Problem/Motivation
Tests in #2575105: Use cache collector for state show that this state key can easily become the largest state key, in two projects, it is 50% of the data in state.
It is also a a perfect use case for using its own collection. it is data that is only needed in rare cases in the backend, we store a list of data per project, so it is its own list and we have API's to store data per-project, which means it is a big overhead to load everything and save everything again for every project we update.
Proposed resolution
Migrate the data to a separate key_value collection and store it per project.
Comments
Comment #2
BerdirFirst patch, seeing some test fails, so something is quite right yet.
Comment #4
BerdirFixed the test and added an update function. I'm just deleting the old data, something we do as well in some cases, we can always refetch it.
Comment #5
vijaycs85Nice cleanup!
I don't see any issues. I believe it's a great improvement. Adding to D8MI sprint (with tags)
Comment #6
BerdirThanks, I unfortunately noticed one small issue, the update number should be 8301 I think.
Comment #7
Sutharsan CreditAttribution: Sutharsan as a volunteer commentedLooking at the existing hook_update_N in core, I conclude you are right with this numbering change.
Comment #8
Sutharsan CreditAttribution: Sutharsan as a volunteer commentedConfirmed: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...
Comment #9
alexpottThe correct number is 8300 - this is documented somewhere.
Nice
Comment #10
BerdirChange record: https://www.drupal.org/node/2836959
Updated the version number.
Comment #11
vijaycs85interdiff looks good.
Comment #12
alexpottCommitted 7147993 and pushed to 8.3.x. Thanks!
Removed a superfluous new line at the end locale.install on commit.
Comment #14
Gábor HojtsyYay, thanks @berdir.