Page MenuHomePhabricator

No PostgreSQL schema name in wiki ID
Open, LowPublic

Description

Author: hansm

Description:
In GlobalFunctions.php, there is a function wfWikiID(). This one always seemed to me like an ad-hoc solution from the time where caching has been introduced. A system wide unique wiki ID is build from the name of the DB and a possible table prefix. From version 1.12 or 1.13 on, this task is lead to a Database object if given as optional argument. And then there is the ForeignDBRepo that has to make a guess on the wiki ID of the repository wiki. Things seem to become more and more complicated.

And actualy, it's so simple: We just want to have a short string that identifies a wiki.

I would like to propose this:

  • Introduce a new global configuration variable, let's say $wgWikiId.
  • Set its default value to what wfWikiID() returns, but only if not set in LocalSettings.php.
  • Add an other parameter to the info array passed to the constructor of ForeignDBRepo. Let's say 'wikiId'. It is the wiki ID of the foreign repository wiki that has to be used when hasSharedCache is set to true.

I think, this would be much more straight forward and even more flexible for those who use MediaWiki in a non-standard installtion. For example, it would solve all the trouble we have with cache keys on our PostgreSQL based cluster with 7 wikis, all in the same DB, but each of them in a separate schema.


Version: 1.14.x
Severity: normal
URL: http://www.wikivoyage.org/de/Benutzer:Hansm

Details

Reference
bz15823

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
InvalidNone
OpenNone

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:21 PM
bzimport set Reference to bz15823.
bzimport added a subscriber: Unknown Object (MLST).

In your proposal, there would be no way to connect to the database of a given wiki ID, which is necessary for the newer applications such as CentralAuth and ForeignDBViaLBRepo.

The problem with the PostgreSQL implementation is that it uses schemas instead of table prefixes, and the schema is not properly represented in the wiki ID. There are two solutions: either use the second part of the wiki ID as a schema in PostgreSQL, or add a third part which will be used to identify the schema.

hansm wrote:

Sorry for the late answer. I don't see the point in your first paragraph. I suppose, the name wikiID has been choosen because its purpose is to identify the wiki uniquely. What has this to do with connecting to the wiki's DB?

I think it would be a missuse of this wikiID to try to extract DB access credentials from this string. But, of course, this is a question of design. Why not adding the DB name, the table prefix (and even the schema) as extra parameters? Anyway, the idea of the ForeignDBViaLBRepo will crash on PostgreSQL as long as the schema is not supported.

Independend of this above issues, I wanted to use this opportunity to tell you how much I appreciate your afforts on making the MediaWiki code more structured. Although you already have done a lot of work on this, there is still a lot to do. ANd, maybe I'm wrong, but sometimes I feel that one of the biggest problems with respect to good structure is the own development team when programming hazardous shortcut solutions.

Cheers

Jdforrester-WMF subscribed.

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.