This has been deployed to Wikidata! And I noticed a minor bug – after editing (even if you just cancel the edit), the snak looks like this:
It’s the same problem that the gadget already used to work around, and I should’ve remembered it – the .valueview.valueview-instaticmode div, which we also need to make display: inline.
Or, much more elegantly: a ConstraintCheckPlan encapsulating all that
Tue, Nov 21
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!
Hm, that was more intended for solutions with a few different results per identical coordinates… I’m not sure if there’s any good way to represent seven thousand results with the same coordinates on a map.
Mon, Nov 20
One possibility to fix the “jumping around” issue would be to get the image sizes from the Commons API (action=query, prop=imageinfo, iiprop=size, titles=…) and to set fixed sizes on the tiles using that, before we start loading the images. However, since the titles parameter is limited to 50 titles per request, that still means several API requests for large result sets… I’m not sure if we can fix the problem completely without reordering the grid in horizontal instead of vertical lines.
Sun, Nov 19
- The browser should only load images in the viewport.
- When scrolling new images should be loaded.
Sat, Nov 18
Sure there is. The one in the query toolbar is for the non-embedded link.
- Provide two buttons on the standard query one as presently, the other for a short link for the "embedded" form.
Fri, Nov 17
Okay, I discussed this with @Ladsgroup and this would be the current draft:
it seems adding --strict-coverage has no effect
Thu, Nov 16
I found a workaround by poking around the query hints:
Here are the result statuses of 100 randomly chosen items (P6333):
With T179844, there is now a small message below the constraint violation indicating if the result is cached. I think that’s enough to resolve this issue, since it’s pretty easy to check manually whether the violation still exists or not if you’re unsure (the gadget shows you a list of other entities, check if those entities still have the same value).
Done, as far as I can tell.
Wed, Nov 15
The simplest fix for this is trivial:
Current result: 38.88%
Core’s Action::getActionName calls the factory function with a WikiPage, apparently:
$action = self::factory( $actionName, $context->getWikiPage(), $context );
Hm, perhaps not, AFAICT it will just move the type error a bit.
I take it the translation from/to item datatype (Q11 ⇔ L5-F11) mentioned in the task breakdown was just for the prototype, and now no longer applies? Or am I misunderstanding something?
Do we really want to cache all constraint check results… or only those that we will actually show in the gadget: warning, violation and bad-parameters?
Regarding invalidation on constraint statement edits – the current median time of the time since a property was last edited is almost 18 days, so just using the revision ID of the property should be acceptable for now.
But I’m already starting to second-guess myself on the connection of this task to T179839: Cache constraint check results :D because there’s a huge difference between caching constraint check results and storing constraint violations. If we want to use the same storage backend for them, that would mean storing some fifty or more¹ “compliance” results for every entity, which is probably way too much to be feasible.
Tue, Nov 14
Okay, after discussion with Thiemo, the new implementation plan is:
I suppose to make this useful, we also need to add a JS hook for when sitelinks are saved (like the existing one for saving statements), so that we can follow the same pattern as recommended for statement indicators: hide the indicators while editing, clear them on save, let gadgets repopulate them after save via the hook.
Mon, Nov 13
you probably want runLast
Duplicate of T175578?
Fri, Nov 10
As far as I’m aware, the last missing part here was T121274: Provide an RDF mapping for external identifiers, which is now fixed. I think we’re waiting for T176593: Reload WDQS dataset so that the new URIs are consistently available in WDQS, but after that, is there anything else left to do before we start submitting requests against DataHub and LODC?