Krinkle updated the task description. (Show Details)

CHANGES TO TASK DESCRIPTION
This RFC is a result of T204024 and specifically the request for an RFC in T204024#4891344

**### Vocabulary**

* WBQC: WikibaseQualityConstraints mediawiki extension, deployed on wikidata.org.
* WDQS: The wWikidata qQuery sService, https://query.wikidata.org.

**### Current situation**

WBQC runs checks on wWikidata entities on demand from users.
Check resultsResults of these constraint checks are stored in memcached with a default ttlTTL of 84600 seconds (1 day).
...
The special page and API can be used by users directly; the API is also called whenever a logged-in user visits an entity page, to display the results on the entity page.

Executions of the API will result in constraint checks being run if stored data is out of date, or not stored / evictcache is absent/expired for the entity.

Executions of the special page currently always re re-run the constraint checks, do not load from the cache and do not store toget or set via the cache.

The RDF page-action iexists for use by the WDQS and will not trigger arun the constraint check runitself, it canit only be used for retrieving theexposes an RDF representadescription of the currently stored constraint checksts that apply to this entity.

When retrieved from the cache, the WBQC extension has logic built in-in to determine if the stored result needs to be updated (because something in the dependency graph has changed).

We are in the process of rolling out a JobJobQueue job that will runre-run constraint checks for an entity post -edit, rather than on only on on-demand by a user. T204031

Once constraint checks are stored more persistently we will be able to expose an event queue of the generation of the checks for ingestion into the WDQS, T201147.
Loading /re-loading of data into the WDQS will also present the need to dump all constraint checks.

55,644 out of 5,767 properties on wWikidata currently have constraints that need to berequire a (cacheable) checked. execution.

Roughly 1.85 million items do not have any statements (currently), leaving 52.05 million items that do have statements and need to have constraint checks run.

Constraint checks also run on Properties and Lexemes but the number there is negligible when compared with Items.

Constraint checks on an item can take a wide variety of times to execute based on the constraints used. Full constraint checks are logged if they take longer than 5 seconds (INFO) or 55 seconds (WARNING) and the performance of all constraint checks is monitored on grafana.

Some full constraint checks reach the current interactive PHP time limit while being generated for special pages or the API.
...
- Constraint check results need to be loaded into WDQS, but there is nowe don't currently a full sehave the result of all constraints check results for all entities on wikidataWikidata items stored anywhere.
...

TASK DETAIL
https://phabricator.wikimedia.org/T214362

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Krinkle
Cc: Marostegui, Joe, daniel, Agabi10, Aklapper, Addshore, Nandana, kostajh, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, merbst, LawExplorer, _jensen, D3r1ck01, SBisson, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to