Page MenuHomePhabricator

Query Service Not Returning Results
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

SELECT ?item ?itemLabel
WHERE 
{
  ?item wdt:P1 wd:Q92 . # This should return instances of "sovereign state".
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } 
}

I've tried a few different functions, but I'm not getting any results returned.

  • Execute the query

What happens?:

No matching records are found.

What should have happened instead?:

Records should have been found and printing in results. The equivalent query, which I've tested on Wikidata functions as expected:

SELECT ?item ?itemLabel
WHERE 
{
  ?item wdt:P31 wd:Q3624078 . 
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } 
}

Software version (skip for WMF-hosted wikis like Wikipedia):

MediaWiki 1.39.3
PHP 7.4.33 (apache2handler)
MariaDB 10.5.15-MariaDB-log
ICU 67.1
Pygments 2.11.2
Lua 5.1.5
LilyPond 2.22.0
Elasticsearch 6.8.23

Other information (browser name/version, screenshots, etc.):

Google Chrome Version 114.0.5735.199 (Official Build) (64-bit)

Event Timeline

I can confirm I also don't see the entries we would expect here.

We had some reports of data being very slow to arrive in other wikis such
as overture-demo.wikibase.cloud last week. Initially I thought it could be
related however in this case it appears that the edits were made a long
time ago. e.g. for Q94 this was back in March.

We should probably look at reloading this wiki's queryservice

Yeah, to be fair the last time I tested the service was maybe more than a couple months ago, and it seemed to be working fine (even updating really quickly), but now nothing is showing up at all-- a reload would be amazing if that's possible!

The following are some internal details:
I took a quick look at this and realised we seem to be missing a simple,
off the shelf way to do a total reload.
I looked at the QsBatch objects for this wiki and saw that the earliest is
May! Clearly far younger than the edits the user is interested in seeing
from March.

See:

QsBatch::where(['wiki_id' => 457])->get()->sortBy('created_at')[0]
=> App\QsBatch {#8103
    id: 1200416,
    eventFrom: 5359653,
    eventTo: 5359656,
    wiki_id: 457,
    entityIds: "Q1,Q2044",
    done: 1,
    created_at: "2023-05-20 12:20:06",
    updated_at: "2023-05-20 12:20:39",
  }

We ought to figure out a way to semi-painlessly do these reloads in a
similar way to ElasticSearch

Tarrow claimed this task.

So what I wrote in T342293#9037896 was a red herring. The issue in this case is that the prefixes are not correctly set. An example query which I think works as expected is:

PREFIX wd: <https://lgbtdb.wikibase.cloud/entity/>
PREFIX wdt: <https://lgbtdb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel
WHERE 
{
  ?item wdt:P1 wd:Q92 . # This should return instances of "sovereign state".
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } 
}

I've therefore gone and marked this as resolved

There's a feature request for some attempt to make this easier to configure and be clear which prefix is being used for what at T335448