Downloading main dumps fails about wikidata-toolkit HOT 5 CLOSED

We already encountered this one yesterday.

We will try to fix this asap.

from wikidata-toolkit.

A temporary workaround is to download the file manually and to put it into the directory following the same patterns as for the other dumps. A maxrevid.txt file should be present there as well, but it can contain any number. We will probably have to remove maxrevid support from WDTK, since there is no good way of finding the maxrevid of a dump now that the HTML changed.

from wikidata-toolkit.

I just added a pull request that will fix this. OTOH, it turns out that the HTML format of the dump pages changed back to how it was before, so that it now works again with the old code too. Anyway, we will remove maxrevid support now rather than relying on such a fragile system.

from wikidata-toolkit.

But we still have to keep the order when processing incremental dump
files. How is this managed now? Btw. I was brought to the idea that
one could tag objects with an revision during the parsing process and
trade the linear dependency for some xml parsing that might be overruled
later on. This would of course give us a boost when doing things in
parallel, but the question is if it is worth the speculative parsing of
things that might show to be out-of-date later on. Just thinking.

from wikidata-toolkit.

The ordering is based on the revision ids that are within the dump file. The change I made just removed revision id support for dumpfiles as a whole. This did not look inside of any dumpfiles, but it just took this data from the Web.

Well, the issue is that revisions in XML in a single page block are usually in ascending order, so what you suggest would almost certainly parallelize work that we would not usually do at all ;-)

from wikidata-toolkit.