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.

In T184529#3888432, @aaron wrote:

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.

In T184529#5308021, @daniel wrote:

In T184529#3888432, @aaron wrote:

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.

In T184529#5308021, @daniel wrote:

@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.

In T184529#5310385, @Tgr wrote:

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

Oh right, thanks!

In T184529#5308021, @daniel wrote:

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.

In T184529#9072491, @Krinkle wrote:

I agree "wiki ID" is not formally specified

FWIW there is some documentation at https://www.mediawiki.org/wiki/Manual:Wiki_ID

The Rdbms feature request to implement yet another getConnection-like method that would take a Wiki ID is one I'd like to decline.

I think it would be nice to have a WikiIdentity class, and consistent with the rest of the architecture. Not so much because the wiki ID / domain mismatch (domains are not supposed to be used outside the DB layer so I don't think that's a problem), objects are just nicer to use than string-represented identities - they are self-documenting and more type safe. Probably not worth the migration burden though.