Last modified: 2012-08-04 20:48:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 15823 - No PostgreSQL schema name in wiki ID
No PostgreSQL schema name in wiki ID
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: crosswiki
Depends on:
Blocks: postgres
  Show dependency treegraph
Reported: 2008-10-04 07:47 UTC by hansm
Modified: 2012-08-04 20:48 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description hansm 2008-10-04 07:47:56 UTC
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.
Comment 1 Tim Starling 2009-01-08 09:21:20 UTC
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. 
Comment 2 hansm 2009-04-09 16:10:31 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.