| Lucas_Werkmeister_WMDE added a comment. |
Oh, and another thing – I suppose we also need to invalidate the cached results somehow when a constraint statement is edited. I’m not sure what the most efficient way to do that is.
- Explicitly purge cached results when a constraint statement is edited. This is almost certainly too expensive.
- Store revision IDs of all properties with constraints in the cached result and reject the result if one of the properties has been edited since then. I’m not sure if this is efficient… constraint checks on Q42 seem to use 122 properties, can we get that many revision IDs in a single database SELECT?
- Keep a global “constraint revision ID” which is only incremented when constraints change, store the current “constraint revision ID” in the cached result and reject it if it’s no longer up to date. However, due to T163465, we currently don’t know in UpdateConstraintsTableJob whether the constraints have actually changed or not, so we would increment that ID with every change to any property, which is actually fairly frequent according to current RecentChanges (about once every five minutes, on average). But I suppose we could also make UpdateConstraintsTableJob smarter – instead of unconditionally purging and re-importing the constraints, get the old ones, import the new ones, compare them, and only store an update if there’s a difference.
- As a combination of the last two ideas, keep such a “constraint revision ID” per constraint (identified by its statement ID), instead of a single global one.
TASK DETAIL
EMAIL PREFERENCES
To: Lucas_Werkmeister_WMDE
Cc: Jonas, Aklapper, Lucas_Werkmeister_WMDE, Lahi, GoranSMilovanovic, QZanden, Agabi10, Wikidata-bugs, aude, Mbch331
Cc: Jonas, Aklapper, Lucas_Werkmeister_WMDE, Lahi, GoranSMilovanovic, QZanden, Agabi10, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
