hoo added a comment. In https://phabricator.wikimedia.org/T124737#1966530, @daniel wrote:
> > I don't see why that would be the case. It seems to me you are under the > > misconception that we purge caches for individual languages, but we don't > > (and can't). > > True, we don't right now. But that is being worked on. Then again, once we > have proper dependency tracking of derived resources, that will itself > replace the entity_usage table (which is just tracking of entities by derived > resources). I see that is planned, but I don't think that we should try to cater for that right now (also eu_touched would be a poor mean to handle that). >> Once MediaWiki decides that the page caches need to get cleared, we throw >> away all entity usages rows (effectively, as we purge all that are older >> than wfTimestampNow()) and then insert the new usages of the (at that point) >> single new ParserCache entry. > > Yes, that was my initial plan. But that means we have to be sure that the > re-rendering and putting-into-the-parser-cache happens after the save & > purge. Which, surprisingly, it often doesn't. In particular, ApiStashEdit > stores the new rendered version into the parser cache before it gets saved. > And it will do so even for previews that never get saved. As discussed on IRC, I don't think that's so hard to get right and stashed edits aren't a problem here, as they don't trigger any of our hook handlers. Keep in mind that core also does post edit updates for all of its tracking tables and it works at least reasonably well. > Btw: conceptually, when tracking dependencies, we need to track the identity > of resource that depends. eu_cache_key would provide this, eu_touched is a > hacky way to get around that requirement. Not necessary (if I understand you correctly). We just need to treat all existing and valid cached versions of a page as a single entity and we're conceptually ok. That doesn't make for an exhaustive list of "dependencies" (across all cached versions that could theoretically exist)… which might not be a very nice way to handle that, but it's enough for our use case. TASK DETAIL https://phabricator.wikimedia.org/T124737 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Aklapper, StudiesWorld, JanZerebecki, aude, daniel, Lydia_Pintscher, hoo, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
