|DarTar created this task.|
DarTar added a project: Wikibase-Containers.
Herald added a subscriber: Aklapper.
Herald added a project: Wikidata.
As part of my weekend experiments with #wikibase-containers, I bumped into a tricky issue preserving data across versions of the query service. I pulled the freshest code and updated the docker images, to see if an issue with the WDQS UI (T186467) had been fixed (and indeed it got fixed)!
However, I noticed that when creating new items and statements in Wikibase, WDQS stopped picking them up. A quick chat with @Addshore suggested that since I updated the query service image, the WDQS index would need to be rebuilt. As Adam explained, "the issue is the updated WDQS version will have differences in the way it stores the data in the index file".
The suggested fix was to delete the volume, or the data from the corresponding directory, and restart blazegraph to start all over again: the index will be rebuilt from recent changes.
The problem is that some of my oldest changes are not in RC any more, since they were made more than 90 days ago AND I never bothered changing the default $wgRCMaxAge on my local instance.
It looks like the way in which the WDQS index is designed depends on the RC api, and as a result I won't be able to recover my older changes unless I go through a full JSON dump export/ingestion.
@Smalyshev can you think of a way to force an index rebuild from the entire revision table as opposed to RC for standalone Wikibase instances? This is an issue that every user of #wikibase-containers sooner or later will bump into. It might also be wise to change the default RC purging period for local Wikibase instances to mitigate this problem.
and I imagine all of your changes are still in the recent changes of your wiki?
In which case it should be able to reload them all from recent changes
Cc: Aklapper, DarTar, Addshore, Smalyshev, Andrawaag, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidatafirstname.lastname@example.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs