Topic on Project:Support desk

I'm upgrading from MediaWiki 1.29.1 to 1.34.0. My wiki uses SQLite.

I noticed that 1.34.0 includes the following new settings when it generates LocalSettings.php (as created for a new, test wiki). I tried adding them to my upgraded wiki's LocalSettings, but this led to the creation of some new, empty databases, and errors when the expected tables couldn't be found.

$wgLocalisationCacheConf['storeServer'] = [
         'type' => 'sqlite',
         'dbname' => "{$wgDBname}_l10n_cache",
         'tablePrefix' => '',''
         'variables' => [ 'synchronous' => 'NORMAL' ],
         'dbDirectory' => $wgSQLiteDataDir,
         'trxMode' => 'IMMEDIATE',
         'flags' => 0
  ];
  $wgJobTypeConf['default'] = [
         'class' => 'JobQueueDB',
         'claimTTL' => 3600,
         'server' => [
                 'type' => 'sqlite',
                 'dbname' => "{$wgDBname}_jobqueue",
                 'tablePrefix' => '',''
                 'variables' => [ 'synchronous' => 'NORMAL' ],
                 'dbDirectory' => $wgSQLiteDataDir,
                 'trxMode' => 'IMMEDIATE',
                 'flags' => 0
         ]
  ];

Questions:

• What is the purpose of these declarations? I suspect it's a performance optimization. Am I right? Is it the kind of optimization that matters to a wiki with only a handful of users?
• Is there a recommended way to create and populate these databases if I decide I want to make use of them?

Basically they are separate databases for things with different write patterns. I assume its to reduce lock contention, since sqlite doesn't support fine-grained locks.

So for the storeServer, that's used by localization cache. Many people use $wgCacheDirectory instead to store this as static CDB files instead of a database.

For the second one (JobQueueDB). That's for storing jobs. When you edit say a template, used on lots of pages, instead of refreshing all those pages immediately, MW splits that over many requests because otherwise the web server may time out. Job queue is for storing and retrieving the list of things to do later.

At the moment, it seems like the definition of these databases is hardcoded in SqliteInstaller::setupDatabase (includes/installer/SqliteDatabase.php), so i guess you could copy the relavent parts.

Sounds to me like the answers then are:

• No, this isn't an optimization I should worry about on my low-traffic site.
• No, it is not the intent that existing wikis will migrate to use this new scheme.

Pretty much.

If performance is critical to you, and you want to optimize things, not using sqlite would probably be the first step