(dev/core#3166) "Metadata" cache - Strictly separate by version
authorTim Otten <totten@civicrm.org>
Sat, 9 Apr 2022 20:23:56 +0000 (13:23 -0700)
committerTim Otten <totten@civicrm.org>
Sat, 9 Apr 2022 20:33:39 +0000 (13:33 -0700)
commita9538f251d2fd267678bdd4c20f2bb9ccede9ebd
tree38854fd35db3a48b1e01d8c18a54c45b89d369cd
parentdedf33a2413f0a4b00f659eb22a56e1dc9dd9a7e
(dev/core#3166) "Metadata" cache - Strictly separate by version

This addresses some symptoms identified in the discussion of 3166.

Before
------

The "metadata" cache is always stored with the name `metadata`.

If you load a newer codebase, it still reads `metadata` from the older code base (until something explicitly clears the cache).

After
-----

The "metadata" cache is always stored with the name `metadata_{version}`, eg `metadata_5_48_0`.

If you load a newer codebase (eg `5.49.0`), it will ignore the older `metadata_5_48_0` and create a new `metadata_5_49_0`.

Comments
--------

The upgrade system also clears cache, but many users rely on navigating through the site to get to the upgrader.

The change could make sense with other caches, but I only applied the change to the `metadata` cache because there is _some_ risk;
eg if some caller bypasses the cache objects. (I was also slightly concerned about the possibility the some caller relies
on `$cache->getName()` or `$cache->getPrefix()` or similar... but I haven't been able to find any methods like that...). It seems
safer to put that sort of change into a monthly update rather than minor patch.
Civi/Core/Container.php