| Lucas_Werkmeister_WMDE added a comment. |
Note: we’ve decided to go ahead with the ObjectCache for now, and store what would be wbqc_result above in the cache instead: see T181060: Cache constraint check results per-entity in ObjectCache (L). We can migrate that to the database, as described above, in the future. In the meantime, review of the above schema is most welcome!
There is also some prior art: an older version of the WikibaseQuality extension contained this table, as found in T102992: [Task] Review WikidataQuality DB schema:
CREATE TABLE IF NOT EXISTS /*_*/wbq_violations ( entity_id VARBINARY(15) NOT NULL, pid VARBINARY(15) NOT NULL, claim_guid VARBINARY(63) NOT NULL, constraint_id VARBINARY(63) NOT NULL, constraint_type_entity_id VARBINARY(15) NOT NULL, additional_info TEXT DEFAULT NULL, updated_at VARBINARY(31) NOT NULL, revision_id INT(10) UNSIGNED NOT NULL, status VARBINARY(31) NOT NULL, PRIMARY KEY (claim_guid, constraint_id) ) /*$wgDBTableOptions*/;
CREATE INDEX /*i*/claim_guid ON /*_*/wbq_violations (claim_guid); CREATE INDEX /*i*/constraint_id ON /*_*/wbq_violations (constraint_id);
Here, each constraint violation gets a database row of its own. In the above form, this table is tied to the notion that constraints are only checked on the main snak of a statement (via the claim_guid column), which is no longer true since T168532: Check constraints on qualifiers and references. However, we could probably construct some alternative “address” that would still, in combination with the constraint ID, be a unique key for such a table. But I’m not sure if that’s an advantage.
Cc: hoo, Ladsgroup, Jonas, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, Agabi10, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
