On 23/04/12 14:45, Daniel Kinzler wrote:
*#* if we only update language links, the page
doesn't even need to be
re-parsed: we just update the languagelinks in the cached ParserOutput object.
It's not that simple, for instance, they may be several ParserOutputs
for the same page. On the bright side, you probably don't need it. I'd
expect that if interwikis are handled through wikidata, they are
completely replaced through a hook, so no need to touch the ParserOutput
objects.
*# invalidate the (parser) cache for all pages that
use the respective item (for
now we can assume that we know this from the language links)
And in such case, you
don't need to invalidate the parser cache. Only if
it was factual data embedded into the page.
I think a save/purge shall always fetch the data. We can't store the
copy in the parsed object.
What we can do is to fetch is from a local cache or directly from the
origin one.
You mention the cache for the push model, but I think it deserves a
clearer separation.
=== Variation: shared database tables ===
(...)
* This approach greatly lowers the amount of space used in the database
* it doesn't change the number of http requests made
** it does however reduce the amount of data transferred via http (but not by
much, at least not compared to pushing diffs)
* it doesn't change the number of database requests, but it introduces
cross-cluster requests
You'd probably also want multiple dbs (let's call them WikiData
repositories), partitioned by content (and its update frequency). You
could then use different frontends (as Chad says, "similar to FileRepo").
So, a WikiData repository with the atom properties of each element would
happily live in a dba file. Interwikis would have to be on a MySQL db, etc.