Fine with me!

So, unless access is needed via a media info caption, we do not need an index.
So if we just want lookup by media info id we can close T227847 and T227848.

Switched to weekly in the latest PR and also fixed the missing ;.
If you give it a +1 I'll go ahead and get it running in the coming days.

@dbarratt @Niharika I added you both to the admin group on test wikidata

I like the changes. The page is much easier to follow now due to its shorter length, and also we no longer need to try and keep the same docs up to date in 2 places!

Also why captions even matter for T223792 - shouldn't getEntity look up by ID (which in case of MediaInfo is straight page id) not by caption?

Indeed, port 80 is hardcoded.

If elastic already has captions indexed then yes this could probably just use elastic. (There would be slightly more delay and potential unpredictability using elastic than some mysql tables like wb_terms).

Note to researcher.
The normal way of this happening would be via the dispatch system.
I imagine whoever does this research will need to look into that a fair bit! :)

I don't think wb_terms should be used at all for media info.
A custom system or new table or set of tables should be decided on, created, and populated.
Temporarily using wb_terms just to remove it would cause more trouble that it is worth and could just lead to it still existing in a few years and us having to do another massive migration.

Not sure what we would gain by adding a panel per entity type.

Not sure if this is done or not, the estimation should perhaps take that into account.

See T227032 :)

Can you confirm that it is still happening on the latest version of the latest tag of the image?
Could you post the image hash and digest you are using?
And also anything you are modifying the image with at runtime (file mounts, env vars, etc)

The re design for items and properties gas already happened.
Mediainfo could benefit from a different design if there are only captions.

The patch above does tracking of # of slots by type for wikibase repos (so commons and wikidata).
I don't think there should be any security implications with this script.
Currently it is set to run daily, there is also a weekly cron it could be moved to.

In T214362#5324623, @daniel wrote:

Moved to the RFC backlog for improvement after discussion at the TechCom meeting. The proposed functionality seems sensible enough, but this ticket is lacking information about system design that is needed to make this viable as an RFC.
Most importantly, the proposal assumes the existence of a "more permanent storage solution" which is not readily available. This would have to be created.

Yes, but this ticket is talking about daily browser tests, not on patch browser tests.

Re opening as we will want to add this to the Local settings file that comes as part of the image :)

Is 1.34 actually required for anything?
Probably best to check with the origional Devs :)
Otherwise let's change that down!

Looks very weird as in?

In T68025#5314328, @ArielGlenn wrote:

Are there visible graphs for these?

I don't know how much work this is.
@Lydia_Pintscher should this still be on the campsite?
Is this ready to be done?

Can we get this added to wikibase.git? :)

The endpoint is hardcoded in https://github.com/wikimedia/analytics-wmde-toolkit-analyzer/blob/35ae8f3796f88443ab9bec18c82881b7a0500162/analyzer/src/main/java/org/wikidata/analyzer/Fetcher/WikiDataFetcher.java#L29

From the logs:

For the TODOS...

In T227504#5315015, @Lydia_Pintscher wrote:

It is theoretically possible for someone to make a statement on Commons that links to a Lexeme, Sense or Form unless you explicitly forbid it.

So most if not all of T119753#1838227 in theory still needs to be done.
But it is all probably pretty low prio, so I'm just going to wrap this ticket up as resolved now.

In T226722#5306871, @Cparle wrote:

Not really sure which JSON structure you mean @Addshore - but yeah, perhaps we should just explicitly index this stuff differently when doing the indexing. That's easy enough atm, but raises 2 questions:

In T227071#5299460, @alaa_wmde wrote:

@Addshore I'd like to put this a trailblazing in the space we have until 01.08. To be followed later with more sub-tasks on the parent one in next trailblazings that focus on developer productivity ( + maintenance on our pipeline as browser tests are causing pain recently)

In T220958#5299597, @alaa_wmde wrote:

If I understand the suggestion correctly, we will then do the following:

• setup tool for detecting/watching cyclic dependencies (maybe other metrics) for our extensions

But if we find a way to wrap WANObjectCache into PSR6 compliant interface won't that be even better.

Same from here

Indeed, let's get rid of oldid :)

So we (WMDE) actually made a daily namespace in graphite for tracking data daily instead of minutely.
We have been using daily metrics there generated from various scripts for a few years now.

That could be an option.
Or we could alter the docker file to just grab the extension at a specific pinned commit for 1.33 that we know works.

In T226093#5310687, @ArielGlenn wrote:

I keep pretty decent tabs on wikidata growth, because of the dumps. I don't do that for commons entities because I can't even find the proper wikibase tables. I checked the wb_* tables on commonswiki and they all appear to be empty (?!)

Would representing captions as captions rather than labels in the JSON structure help?
Or rather than pretending media info entities are totally like items / properties just have totally different handling for them when it comes to indexing?