| Lucas_Werkmeister_WMDE added a comment. |
Here are the result statuses of 100 randomly chosen items (P6333):
"bad-parameters" 15 "warning" 66 "not-main-snak" 1601 "todo" 26 "compliance" 5096
It appears the average item has plenty of checkable snaks, but very few violations (which is great!). So I’m very much leaning towards the optimization mentioned in the previous comment: to only store those results that the gadget will display (here: 81 out of 6800).
And in that case, we should seriously consider using the same storage mechanism for both T180582: List of all constraint violations? and this task, since they’ll contain the same information. (That is: for now, cache constraint check results; later, add a special page that lists cached constraint check results of a property across all entities that use it; and perhaps later still, add a job that periodically checks constraints on random items, so that the constraint results of the special page don’t depend on human editors visiting items with the checkConstraints gadget enabled.) I’m just not sure how best to do that.
The task is: we have a JSON blob (or, if you will, a PHP array – the constraint check results, in any event), which we want to store for some time (with the ability to explicitly remove it, either on page purge or because we detect it’s no longer valid). Currently, we will access it by entity ID (one blob per entity), but in the future, we will also want to find it by a list of property IDs, and possibly constraint IDs (statement IDs), that it involves. That list can be determined from the blob, but not with a simple string search.
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
