This used to work, see T196297 (but we didn't write tests back then :S )

Also results in error: https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&origin=*&ids=L11533-F7&languages=de&languagefallback=1

@fgiunchedi @Smalyshev How about I do something like this:

$result = json_decode(file_get_contents('http://prometheus.svc.eqiad.wmnet/ops/api/v1/query?query=blazegraph_lastupdated'), true)['data']['result'];
foreach ( $result as $resultByInstance ) {
	echo $resultByInstance['metric']['instance'] . ' (' .$resultByInstance['metric']['cluster'] . ') has been updated at ' . $resultByInstance['value'][1] . PHP_EOL;
}

wdqs1004:9193 (wdqs) has been updated at 1557755605
wdqs1005:9193 (wdqs) has been updated at 1557755946
wdqs1006:9193 (wdqs) has been updated at 1557758395
wdqs1003:9193 (wdqs-internal) has been updated at 1557758386
wdqs1007:9193 (wdqs-internal) has been updated at 1557758374
wdqs1008:9193 (wdqs-internal) has been updated at 1557758353
wdqs1009:9193 (wdqs-test) has been updated at 1557758403
wdqs1010:9193 (wdqs-test) has been updated at 1557758409

This has always been the case: Ever since that was introduced with 9f25055cd98293aa0b49fe16acd9490b231b29c1 (the function was later renamed, but this is about the implementation).

Per https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/509437#message-f7b925c6397cdb5a95b2561998b51e3d7c798d51: "can be merged after Tuesday next week." (so after May 14)

@Michael In https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/509100#message-105c66f111a3e15944690f1bef71889e210a61b5 you said that https://gerrit.wikimedia.org/r/509356 will probably fix all of that? So… is this done, can we abandon the other patches?

@WMDE-leszek Why was this reopened?

@Smalyshev Do you think it would be enough to look at http://prometheus.svc.eqiad.wmnet/ops/api/v1/query?query=blazegraph_lastupdated and http://prometheus.svc.codfw.wmnet/ops/api/v1/query?query=blazegraph_lastupdated (no matter which DC MW is running in) and just take all servers into account? Or do we need a whitelist/blacklist (or both) or some other mechanism to make sure we don't eg. take servers into account that are being maintained.

In T222259#5159066, @Lea_Lacroix_WMDE wrote:

I still see the "edit" text on https://wikidata-shex.wmflabs.org/w/index.php?title=EntitySchema:E44&action=edit does it mean it's not yet merged?

Alternative approach:

Did one minor change (as we renamed the configuration variable): https://www.mediawiki.org/w/index.php?diff=3221303&oldid=3219705

Possible way to do this:

Maybe the change to how we serialize things affected that item?

In T220904#5140840, @daniel wrote:

Change SlotRecord::hasSameContent to no longer take the size into account (given the other criteria checked in there, I guess this would be fine)

Comparing the hash would be sufficient, but it's expensive if the hash isn't in the database (can't happen with the new schema, but the new schema isn't even the default yet). But doesn't the hash also depend on the php serialization?... Or is that based on the entity's json serialization for some reason?

I just checked this for the revisions 889025858 and 917938818. Both refer to equal content blobs (before and after inflating).

In T221104#5130208, @Lucas_Werkmeister_WMDE wrote:

To be honest, I’m starting to doubt the usefulness of this commenting-out spree. There are now more commented-out scenarios than ones left active, and the way that different test failures appear and vanish between test runs makes me think that most of the failures aren’t related to any individual test.

In T212869#5122970, @Lucas_Werkmeister_WMDE wrote:

Unfortunately the ChangeOp approach seems to have the same problem: it uses the base revision, not the parent revision, to check if the label and the description are the same :(

While I understand your point, I fair that isolating some data from the main dump is only a temporary solution to its size growth. Sooner or later, it will weight 1 TB (even compressed), and we'll have to deal with this (as producer or as consumer).

AFAICT the patch linked above just needs some more love (mainly a configuration changelog should be added). Despite of that, I think we're good to go here… does anyone want to pick this up? Otherwise I'll have a look.

In T220883#5127292, @Lydia_Pintscher wrote:

Is anything missing before we can create those separate dumps? Any decisions we still need to take?

In T173008#3863378, @Lydia_Pintscher wrote:

So let's be realistic and close this ticket?

Problem on the demo site fixed, this just needs an OOUI release now.

I assume this is complete for now, but please see T210598#5110640 before closing.

Why not do this as part of ChangeOpDescription and ChangeOpLabel? I know some places don't use this, but this seems to be the right place to me.

In T125352#3952803, @samuwmde wrote:

Hej Marius is this still relevant?

The test page Lucas set up looks good now: https://wikidata.beta.wmflabs.org/wiki/Talk:Q15905