Page MenuHomePhabricator

Define a way to get a database connection based on a logical wiki ID.
Open, NormalPublic

Description

The idea of a "wiki ID" for (at least) sites in the local cluster is used in MediaWiki in several places, such as

  • wfWikiID()
  • WikiMap::getWiki()
  • SiteConfiguration::getSetting()
  • Site::getGlobalId()

LoadBalancer::getConnection used to have a $wiki parameter, which has recently be renamed to $domain. This parameter assumes that the ID provided encodes a database name (and possibly a schema name and a suffix). However, the relationship between the symbolic name used by SiteConfiguration and friends and the database name is not specified anywhere, and the two do not quite work the same in some edge cases (such as the database name containing a dash).

In order to allow application logic to reliable connect to the database of another wiki in the local cluster, there needs to be a way to obtain a database connection given a logical wiki ID. This is currently only possible if that symbolic name is the same as the database name, and does not contain any special characters. This relationship should at least be documented, but ideally, a proper mapping should be provided.

Event Timeline

daniel created this task.Jan 9 2018, 3:25 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 9 2018, 3:25 PM
aaron added a comment.Jan 9 2018, 11:00 PM

I see wiki IDs as a type of "domain ID" that just uses two ASCII components, (dbname,prefix), neither using slashes to avoid the ugliness of using things like "mysite?hnewswiki-en" have to appear on config or in "table_wiki" DB fields. For B/C, the non-slash rule can't be a hard-rule that throws errors. Given that, the getWiki() functions should use known-to-be-encoded wiki ID values or use use DatabaseDomain to derive them. There could be a stricter WikiDatabaseDomain subclass. Changing those methods would probably both fix and break things for the slash-scenario; maybe the "doesn't use domain hierarchy delimiter character" restriction could then be enforced by default behind a flag that could be disabled for legacy-mode.

238482n375 set Security to Software security bug.Jun 15 2018, 8:06 AM
238482n375 added a project: Security.
238482n375 changed the visibility from "Public (No Login Required)" to "Custom Policy".
238482n375 added a subscriber: 238482n375.
This comment was removed by akosiaris.
akosiaris changed the visibility from "Custom Policy" to "Public (No Login Required)".
akosiaris removed a subscriber: 238482n375.
Restricted Application added a project: Security. · View Herald TranscriptJun 15 2018, 11:28 AM
akosiaris added a subscriber: akosiaris.
daniel added a subscriber: Tgr.Jul 5 2019, 10:14 AM

I see wiki IDs as a type of "domain ID" that just uses two ASCII components, (dbname,prefix), neither using slashes to avoid the ugliness of using things like "mysite?hnewswiki-en" have to appear on config or in "table_wiki" DB fields.

I think using strings for this at all is a big problem. And encoding any "real" information into these strings makes it even worse. Wiki IDs should be totally opaque identifiers, and we should have a class to model them. @Tgr and I discussed this at the hackathon, but it seems we didn't write it down. I made a ticket now, see T227305: Define a WikiID class for uniquely identifying wikis.

aaron added a comment.Jul 5 2019, 10:58 PM

I see wiki IDs as a type of "domain ID" that just uses two ASCII components, (dbname,prefix), neither using slashes to avoid the ugliness of using things like "mysite?hnewswiki-en" have to appear on config or in "table_wiki" DB fields.

I think using strings for this at all is a big problem. And encoding any "real" information into these strings makes it even worse. Wiki IDs should be totally opaque identifiers, and we should have a class to model them. @Tgr and I discussed this at the hackathon, but it seems we didn't write it down. I made a ticket now, see T227305: Define a WikiID class for uniquely identifying wikis.

I don't mind things like UUID strings that could add global-wiki ID features. LBFactory::setDomainAliases() could easily inject those opaque strings and map them to DB domain IDs.

Tgr added a comment.Jul 5 2019, 11:36 PM

@Tgr and I discussed this at the hackathon, but it seems we didn't write it down.

You did create T224020: Create a class to represent the identity of wikis on the same wiki farm based on that.

Anomie added a comment.Jul 9 2019, 4:49 PM

I think using strings for this at all is a big problem. And encoding any "real" information into these strings makes it even worse. Wiki IDs should be totally opaque identifiers, and we should have a class to model them.

You can't easily use a class in configuration files, and UUIDs tend not to mean anything to humans writing the config files or looking at them to try to figure out what's going on.

See T224020#5317911 for further reply. Having things split between this, T224020, T221535, T113034, and possibly other tasks is just going to confuse things.

Krinkle triaged this task as Normal priority.Jul 23 2019, 5:11 PM