Lucas_Werkmeister_WMDE added a comment.
Yes, it hasn’t been done yet. There are some patches on Gerrit for my old ConstraintCheckPlan idea, but I’m not sure if that’s the best approach, and the patches themselves are probably stale beyond saving by now.TASK
Addshore added a comment.
In T163683#3913304, @Lucas_Werkmeister_WMDE wrote:
Overall, it seems like with this optimization, we might be able to save, very roughly speaking, about half of all type constraint checks we perform. (Note, however, that this doesn’t help the “value type” constraint,
Lucas_Werkmeister_WMDE added a comment.
I tried to find out how many constraint checks we could save with this, specifically for the type constraint, which is the most expensive one out of the three where we can apply this optimization. This query, if I’m not mistaken, tells us that on Q42
gerritbot added a comment.
Change 392054 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add tests for ConstraintCheckPlan
https://gerrit.wikimedia.org/r/392054TASK
gerritbot added a comment.
Change 374592 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Introduce ConstraintCheckPlan class
https://gerrit.wikimedia.org/r/374592TASK
Lucas_Werkmeister_WMDE added a comment.
It should also be possible to deduplicate constraint checks on references. The same reference can be used in multiple statements, even across entities. (“imported from: English Wikipedia”, wdref:fa278ebfc458360e5aed63d5058cca83c46134f1 in RDF, is used in
Lucas_Werkmeister_WMDE added a comment.
We probably also want to normalize constraint parameters before deduplication, by deterministically sorting the snaks (by property and value). I think this can be done without parsing the constraint parameters, just acting on the JSON as opaque blobs.TASK
