Page MenuHomePhabricator

[Task] Have a reliable way to invalidate SiteStore cache when running populateSitesTable
Open, MediumPublic

Description

when we update the sites table, we need a reliable way to invalidate cache.

If the cache key could somehow incorporate last update time for the sites table, that might work. Essentially, the cache key needs to change.

the cache key is currently something like:

wikidatawiki:sites/SiteList#2014-03-17+Site:2013-01-23

(the dates being constants tied to the format of SiteList and Site, so when those change the cache gets bumped. but those are not the only possible reasons for invalidating this cache)

Without doing anything, the cache has an expiry of an hour. Perhaps, alternatively we could make that somewhat shorter and then just be patient?

Event Timeline

aude raised the priority of this task from to Needs Triage.
aude updated the task description. (Show Details)
aude subscribed.

SiteStore has a cache expiry of 3600 seconds (an hour). maybe that is okay enough? or we could make it shorter?

aude renamed this task from Base the SiteStore cache key on config + constant in SiteStore to Have a reliable way to invalidate SiteStore cache when running populateSitesTable.Sep 10 2015, 10:32 AM
aude renamed this task from Have a reliable way to invalidate SiteStore cache when running populateSitesTable to [Task] Have a reliable way to invalidate SiteStore cache when running populateSitesTable.
aude triaged this task as Medium priority.
aude updated the task description. (Show Details)
aude set Security to None.

ultimately I think we want to move away from having this in the database, as it really is configuration.

We could have generated php files, and then when they change, anything cached is invalidated.

Daniel has more ideas about this: https://www.mediawiki.org/wiki/User:Duesentrieb/Fix_interwiki