| daniel added a comment. |
Some thoughts/options for for caching:
- web caches are easy to set up, but hard or impossible to purge
- the result of a SPARQL based regexp evaluation could be cached forever in the WDQS web cache
- the result of a SPARQL based instanceof check can be cached "for a while" in the WDQS web cache
- using a web cache for the output of the wbcheckcontraints API module woud make it quite hard to purge the result
- any cached constraint results for a given statement must be purged/discarded when the statement is edited (or when anything on the respective entity is edited)
- We could use the object cache (BagOStuff and friends) to cache results for an entire entity.
- The cache key could include the revision ID, which would enable automatic purging on every edit.
- We could use the object cache (BagOStuff and friends) to cache results for individual statements
- the cache key for a per-statement result could contain the statement hash, which would enable automatic purging when the statement changes
- The object cache timeout should be low enough to allow changes to constraint declarations to take effect not too long after they are mode (hours? how many?)
- Any constraints that use only local info can be cached until the entity (or statement) changes.
- Constraints using global data should only be cached for a relatively short time. Unfortunately, these are also the ones that are expensive to evaluate.
TASK DETAIL
EMAIL PREFERENCES
To: daniel
Cc: daniel, Aklapper, Jonas, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, Agabi10, Izno, Wikidata-bugs, aude, Mbch331
Cc: daniel, Aklapper, Jonas, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, Agabi10, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
