Change Details

I just discovered that FactGrid’s second largest table (after `text`) is `wb_changes`, presumably because it never occurred to the wiki admins (including me) that we should run the `pruneChanges.php` maintenance script. Similarly, I’m not sure if change dispatching (to the wiki as its own client) works properly, because I don’t think we ever set up a `dispatchChanges.php` cronjob. All we have is a systemd service that keeps running `runJobs.php`, under the assumption that this is all that you need to keep a MediaWiki instance running. There are probably good reasons for having change dispatching and pruning in separate scripts on Wikidata. But I think it would make managing smaller Wikibase wikis much easier if by default, Wikibase arranged for “everything necessary” to happen through the job queue, without requiring additional maintenance scripts. (There would be a few additional settings for things like the `pruneChanges.php` “keep” and “grace” periods, with reasonable defaults.)

I just discovered that FactGrid’s second largest database table (after `text`) is `wb_changes`, presumably because it never occurred to the wiki admins (including me) that we should run the `pruneChanges.php` maintenance script. Similarly, I’m not sure if change dispatching (to the wiki as its own client) works properly, because I don’t think we ever set up a `dispatchChanges.php` cronjob. All we have is a systemd service that keeps running `runJobs.php`, under the assumption that this is all that you need to keep a MediaWiki instance running. There are probably good reasons for having change dispatching and pruning in separate scripts on Wikidata. But I think it would make managing smaller Wikibase wikis much easier if by default, Wikibase arranged for “everything necessary” to happen through the job queue, without requiring additional maintenance scripts. (There would be a few additional settings for things like the `pruneChanges.php` “keep” and “grace” periods, with reasonable defaults.)

I just discovered that FactGrid’s second largest database table (after `text`) is `wb_changes`, presumably because it never occurred to the wiki admins (including me) that we should run the `pruneChanges.php` maintenance script. Similarly, I’m not sure if change dispatching (to the wiki as its own client) works properly, because I don’t think we ever set up a `dispatchChanges.php` cronjob. All we have is a systemd service that keeps running `runJobs.php`, under the assumption that this is all that you need to keep a MediaWiki instance running. There are probably good reasons for having change dispatching and pruning in separate scripts on Wikidata. But I think it would make managing smaller Wikibase wikis much easier if by default, Wikibase arranged for “everything necessary” to happen through the job queue, without requiring additional maintenance scripts. (There would be a few additional settings for things like the `pruneChanges.php` “keep” and “grace” periods, with reasonable defaults.)