On 11/12/13 22:56, Daniel Kinzler wrote:
The thing is: we are changing what's in the list
of relevant options. Before the
deployment, there was nothing in it, while with the new code, the user language
should be there. I suppose that means we need to purge these "pointers".
Would bumping wgCacheEpoch be sufficient for that? Note that we don't care much
about puring the actual parser cache entries, we want to purge the "pointer"
entries in the cache.
Yes, bumping $wgCacheEpoch is sufficient. It's not possible to purge
the pointer entries without also invalidating the actual parser cache
entries, since changing the set of used options will change all of the
parser output keys.
If you just deploy the code without bumping $wgCacheEpoch, the
pointers will be overwritten each time a parser cache entry is saved,
effectively unlinking all the existing variants of that parser cache
entry. So it would sort itself out eventually, without any pollution.
It's not
necessary to call ParserOutput::recordOption().
ParserOptions::getUserLangObj() will call it for you (via
onAccessCallback).
Oh great, magic hidden information flow :)
Yeah, there's a tradeoff between the system being easy to use and
being easy to understand. Most people who write parser extensions are
pretty naïve about how the parser cache works, which is why I accepted
Platonides' idea of using ParserOptions accessor calls to determine
cache-varying options, in r70783. It seemed to have the best chance of
working with naïvely written extensions.
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/70783
-- Tim Starling