Also option 5 could be to continue without the days until the parser cash
is invalidated on its own.
Maybe option 6 could be to continue without the data and invalidate the
cache and completely rerender only some of the time. Like 5% of the time
for the first couple hours then 25% of the time for a day then 100% of the
time after that. It'd guarantee that the cache is good after a certain
amount of time without causing a big spike ridge after deploys.
All those options are less good then just updating the cache I think.
Nik
On Sep 9, 2014 6:42 AM, "aude" <aude.wiki(a)gmail.com> wrote:
On Tue, Sep 9, 2014 at 12:03 PM, Daniel Kinzler
<daniel(a)brightbyte.de>
wrote:
Hi all!
tl;dr: How to best handle the situation of an old parser cache entry not
containing all the info expected by a newly deployed version of code?
We are currently working to improve our usage of the parser cache for
Wikibase/Wikidata. E.g., We are attaching additional information related
to
languagelinks the to ParserOutput, so we can use
it in the skin when
generating
the sidebar.
However, when we change what gets stored in the parser cache, we still
need to
deal with old cache entries that do not yet have the desired information
attached. Here's a few options we have if the expected info isn't in the
cached
ParserOutput:
1) ...then generate it on the fly. On every page view, until the parser
cache is
purged. This seems bad especially if generating the required info means
hitting
the database.
2) ...then invalidate the parser cache for this page, and then a) just
live with
this request missing a bit of output, or b) generate on the fly c)
trigger
a
self-redirect.
3) ...then generated it, attach it to the ParserOutput, and push the
updated
ParserOutput object back into the cache. This seems nice, but I'm not
sure
how
to do that.
https://gerrit.wikimedia.org/r/#/c/158879/ is my attempt to update
ParserOutput cache entry, though it seems too simplistic a solution.
Any feedback on this would be great or suggestions on how to do this
better, or maybe it's crazy idea. :P
Cheers,
Katie
4) ...then force a full re-rendering and re-caching of the page, then
continue.
I'm not sure how to do this cleanly.
So, the simplest solution seems to be 2, but it means that we invalidate
the
parser cache of *every* page on the wiki potentially (though we will not
hit the
long tail of rarely viewed pages immediately). It effectively means that
any
such change requires all pages to be re-rendered eventually. Is that
acceptable?
Solution 3 seems nice and surgical, just injecting the new info into the
cached
object. Is there a nice and clean way to *update* a parser cache entry
like
that, without re-generating it in full? Do you
see any issues with this
approach? Is it worth the trouble?
Any input would be great!
Thanks,
daniel
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
@wikimediadc / @wikidata
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l