Acceptance criteria:
1 week sprint 20: Make a plan for testing that covers what to test and what platform to test it on
1 week sprint 21: Execute plan made above (add details in AC as soon as we know what to do)
Acceptance criteria:
1 week sprint 20: Make a plan for testing that covers what to test and what platform to test it on
1 week sprint 21: Execute plan made above (add details in AC as soon as we know what to do)
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T91505 [Epic] Adding new datatypes to Wikidata (tracking) | |||
Open | None | T214884 [ES-M2]: [EPIC] Linking EntitySchemas in statements | |||
Resolved | Ifrahkhanyaree_WMDE | T354778 Build a solution in Wikibase for EntitySchemas to be returned with valuetype wikibase-entity | |||
Resolved | Ifrahkhanyaree_WMDE | T359420 [Timebox] Performance testing |
We looked at some requests through XHGui and are now convinced that the performance impact is negligible and doesn't require more elaborate testing. We stumbled upon a worst case scenario while looking at a page on Wikivoyage accessing item data (profile) in which all property info was requested from the database, which took 240ms for PropertyInfoTable::getAllPropertyInfo with an inclusive wall time of 274ms for all 3162 calls to CachingPropertyInfoLookup::getPropertyInfo. Subsequent requests to the same page took ~20ms for all calls to getPropertyInfo. Given that even expensive wbcheckconstraints requests aren't going to exceed this dramatically (13604 calls to needsDataTypeLookup here, only some of which will actually result in lookups), we feel confident that this is fast enough.