Am 10.12.2013 22:38, schrieb Brad Jorsch (Anomie):
Looking at the code, ParserCache::getOptionsKey() is used to get the memc key which has a list of parser option names actually used when parsing the page. So for example, if a page uses only math and thumbsize while being parsed, the value would be array( 'math', 'thumbsize' ).
Am 11.12.2013 02:35, schrieb Tim Starling:
No, the set of options which fragment the cache is the same for all users. So if the user language is included in that set of options, then users with different languages will get different parser cache objects.
Ah, right, thanks! Got myself confused there.
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.
We just tried to enable the use of the parser cache for wikidata, and it failed, resulting in page content being shown in random languages.
That's probably because you incorrectly used $wgLang or RequestContext::getLanguage(). The user language for the parser is the one you get from ParserOptions::getUserLangObj().
Oh, thanks for that hint! Seems our code is inconsistent about this, using the language from the parser options in some places, the one from the context in others. Need to fix that!
It's not necessary to call ParserOutput::recordOption(). ParserOptions::getUserLangObj() will call it for you (via onAccessCallback).
Oh great, magic hidden information flow :)
Thanks for the info, I'll get hacking on it!
-- daniel
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
wikidata-tech@lists.wikimedia.org