Page MenuHomePhabricator

Consolidate places that read/write 'wb_changes' table
Closed, ResolvedPublic

Description

We now have a separate extracted library for handling 'Changes': See: https://github.com/wikimedia/wikibase-changes

This nicely encapsulates much of the business logic for working with changes on both client and repo.

What it does not do is encapsulate the reading and writing of the table that is shared between client and repo.

A number of places are making raw reads to this table (including maintenance scripts): e.g.

  • extensions/Wikibase/client/includes/Store/Sql/BulkSubscriptionUpdater.php
  • extensions/Wikibase/repo/includes/ChangePruner.php
  • etc..

There already exists an store Class that could be used: extensions/Wikibase/lib/includes/Store/Sql/SqlChangeStore.php

Acceptance Criteria:

  • There should be one place that consolidates the code that reads or writes to the changes table (or perhaps two e.g. reading and writing split)
  • This code should be available to both client and repo (e.g. it should be placed in a shared composer library)

Event Timeline

Tarrow renamed this task from Consolidate places that read/write 'wb_changes' to Consolidate places that read/write 'wb_changes' table.Aug 10 2020, 7:50 AM
Tarrow updated the task description. (Show Details)

Now that I'm looking more into this: do we want something similar also for the other Changes-related tables? I.e. wb_changes_dispatch, wb_changes_subscription and wbc_entity_usage?

wbc_entity_usage is technically not part of changes, it's a client feature basically.

The wb_changes table is now only written by a single class \Wikibase\Lib\Store\Sql\SqlChangeStore and read by two classes:

  • \Wikibase\Lib\Store\Sql\EntityChangeLookup for loading the actual changes themselves
  • \Wikibase\Repo\Store\Sql\DispatchStats for reading meta data (number of rows and entities, freshest and stalest)

All of this access above is now happening exclusively from the side of a Wikibase Repo.

Further, the table is read from analytics scripts.

I'm not sure that there is realistically anything left to do here?

(And the wb_changes_dispatch table is gone, see T291829. wb_changes_subscription still exists.)

I would agree that this can be closed.