Page MenuHomePhabricator

Ensure keep both "site numeric identifier" and "site string identifier" during changes to site/site matrix/sites data/database tables
Open, Needs TriagePublic

Description

Ensure keep both "site numeric identifier" and "site string identifier" during changes to site/site matrix/sites data/database tables

For example, both "site numeric identifier" and "site string identifier are both exposed and used on Fandom:

https://community.fandom.com/wiki/

>> mw.config.get( "wgCityId" );
<- 177
>> mw.config.get( "wgWikiID" );
<- "wikia"

Event Timeline

Why? What’s the point of having two IDs for each wiki? What are the tasks wgCityId is used for, and couldn’t those be migrated to use wgWikiID instead? (Why is it called a “city ID” at all?)

I don't know the specifics here, but as a general rule, we should avoid exposing automatically assigned numeric identifiers if there is a stable human readable equivalent. We are getting this right e.g. for change tags and content models, we got it wrong (a long time ago) for namespaces. The preferred internal mechanism for this is using a NameTableStore to maintain the mapping, it can be attached to any database table that allows a lookup in both directions.

Actually, what @daniel wrote could work as a custom solution: if Fandom needs numeric IDs, it could just maintain a custom database table (or any other form of a mapping, e.g. a huge PHP array) for itself. Given that the chosen solution for large wiki farms is to plug their own sites configuration method into core (I assume Fandom also has one, although its Special:Version is full of broken links, so I don’t know what), that own sites configuration could continue to store the numeric IDs and make them available via a custom means – if it’s really needed to be available cross wiki. I just realize that the code sample you gave is querying the “city ID” of the current wiki; that doesn’t need sites support at all (the sites configuration is about wikis querying data about each other, not about themselves).

I suggest declining this task and advising Fandom to develop a custom in-house solution if they really need the mess of two kinds of wiki IDs.