Last modified: 2012-08-04 20:48:47 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.
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.
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
