| Lucas_Werkmeister_WMDE added a comment. |
Okay, my current notion of the caching is: we use just the entity ID as cache key (plus some static WBQC prefix, of course). The value includes not just the serialized constraint check results, but also a map of page titles to revision IDs. When retrieving a cached value, we don’t even care what those titles are, we just check they’re all still up to date, and otherwise delete this value from the cache. When computing a value to cache, that map includes the entity currently being checked, all entities referenced in “inverse”, “symmetric” and “target requires claim” constraints (perhaps with some reasonable limit, 100 or so), and perhaps also all properties used in constraints (but I’m not sure about that yet, see above). We also hook into the ArticlePurge hook to purge an entity’s cached constraint check results when that entity is purged, but we don’t purge any other entities in that hook.
Cc: Jonas, Aklapper, Lucas_Werkmeister_WMDE, Lahi, GoranSMilovanovic, QZanden, Agabi10, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
