Skip to content

Read large countries' towns by id in batches and every station in one query, and keep last month's towns for a country that fails - #6

Open
davd-gzl wants to merge 7 commits into
mainfrom
country-queries-in-parts
Open

davd-gzl wants to merge 7 commits into
mainfrom
country-queries-in-parts

Conversation

@davd-gzl

@davd-gzl davd-gzl commented Nov 1, 2026 •

Copy link
Copy Markdown
Contributor

Before: the monthly Wikidata fetch on 1 November ran for 351 of its 355 minutes, then stopped without publishing anything. The queries for the towns of Italy, Japan and the United States, and for Japan's stations, kept hitting the query service's 60-second limit, and three countries with no towns is more than the fetch allows.

Splitting a country into five parts by the last digit of each item's id does not save the towns. The digit filter has to read the id of every item with a population worldwide, 147,222 of them, so it costs 27 seconds before the details are read, and a fifth of the United States still timed out.

After: when a country's whole town query fails, the fetch reads its town ids alone, then their details 500 towns at a time. Stations come from one query for the whole world instead of one per country, and a failure there stops the run before the sights. A country whose towns still can't be read keeps what the last committed fetch had for it, so a bad day at the query service leaves last month's data in place instead of failing the run. More than 10 countries kept fails the run, since a broken query would otherwise publish last month's data for every country under today's date. The town query checks whether a class is a kind of town once per class instead of once per item.

How:

  • townIdsQuery returns a country's town ids and citiesByIdQuery the details of a list of ids. citiesQuery builds the same text as before from the same two pieces.
  • STATIONS_QUERY reads every open railway station on Wikidata. COUNTRY_CODES_QUERY and labelsQuery add their countries and their names, 5,000 stations at a time, since reading either in the same query went past the one-minute limit.
  • fetch.ts tries each whole town query twice, it used to try three times, then falls back to the batches, then to the previous data/raw/wikidata.json through keepPrevious.
  • FETCH_IN_PARTS=1 skips the whole queries, and fewer than 5,000 United States towns read that way now fail the live Wikidata check.

Live check on 2 and 3 November, with no previous file:

  • United States: 7,811 towns from 7,958 ids in 16 batches, read in 6 minutes with no batch failing.
  • Italy: 2,760 towns. Japan: 1,314 towns.

The stations took 151 of the 351 minutes on 1 November, in 255 queries, one per country. The sights of the towns that now come back add about 30 minutes.

The monthly fetch on 1 November left out the towns of Italy, Japan and the
United States and the stations of Japan: their queries hit the query
service's time limit three times each, so the run stopped with nothing
published. A country whose query fails is now read in five parts, by the
last digit of each item's Wikidata id, and its whole query is tried twice
rather than three times.
Read in parts, Great Britain and the United States still timed out: the
check that an item is a kind of town walked the class tree once per item.
It now runs once per class, in its own subquery, and the slow way reads
only the populations large enough, as an index range. The live check now
fails when a country's towns or stations are left out, which only warned.
A country whose towns or stations can't be read, even in parts, now keeps
what the committed copy had for it, so a bad day at the query service
leaves last month's data rather than failing the whole run. The populations
are read as before: the index-range hint was not proven to help. The live
check goes back to warning on a country left out, as the query service's
load decides that more than the code does.
@davd-gzl davd-gzl changed the title Read a country in parts when its whole query times out Read large countries in parts, and keep last month's data for a country that fails Nov 1, 2026
davd-agent added 2 commits November 3, 2026 00:27
Splitting a country by the last digit of each item's id left a fifth of
the United States still timing out: the digit filter reads the id of
every item with a population worldwide before any detail is read. A
country whose whole town query fails now has its town ids read alone,
then their details 500 at a time. Stations keep the parts.

The live check reads Japan and the United States the slow way and fails
when fewer than 5,000 United States towns come back.
keepPrevious moves to src/wikidata.ts so a test can reach it: a country
this run missed gets what the last fetch had for it, and only the ones
it had nothing for count as left out.
@davd-gzl davd-gzl changed the title Read large countries in parts, and keep last month's data for a country that fails Read large countries' towns by id in batches, and keep last month's data for a country that fails Nov 2, 2026
davd-agent added 2 commits November 3, 2026 00:37
A run where every station query fails kept every country's stations from
the last fetch and passed, publishing them under today's date. More than
10 countries kept, for towns or stations, now fails the run.
The stations took 151 of the 351 minutes on 1 November, in 255 queries,
one per country, each reading every station on Wikidata. One query now
reads them all, with their countries and names read by their own
queries, and a failure there stops the run before the sights. The digit
parts go: nothing reads a country in parts any more.
@davd-gzl davd-gzl changed the title Read large countries' towns by id in batches, and keep last month's data for a country that fails Read large countries' towns by id in batches and every station in one query, and keep last month's towns for a country that fails Nov 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant