I'm strongly in favor of getting rid of the mess that is $wgSharedTables. Any mechanism that supports sharing tables needs to be designed to be aware of that, using appropriate methods to get database handles that are documented as being on possibly different databases. The caller would at least know that certain tables are co-located.

The virtual domain config and virtual domain aware connection methods indeed seem like they fit this use case. Anything actually designed to support table sharing can be converted to using the getPrimaryDatabase()/getReplicaDatabase() methods.

@aaron I support removing wgSharedTables. To my knowledge it is in practice only used for sharing user tables, which we're perhaps better off doing explicitly instead of pretending that we allow any arbitrary table to be shared. Which is maintenance-heavy at best, and a footgun at worst.

Can this work without requiring sysadmins to hardcoded a lot of entries internal table names? Assuming the same virtual domain can be used for multiple tables, I guess yes. E.g. we'd register virtual-user akin to how we have virtual-botpasswords in core already, and use it for user/actor/user_properties/etc accordingly.

In terms of configuration, that would turn $wgSharedDB effectively into a a boolean feature flag, much like how it is already. Except no longer configurable via wgSharedTables but rather specifically for shared user accounts, automatically plugged into $wgVirtualDomainsMapping['virtual-user'] or something like that, for compat.

Apparently SpamRegex and MultiMail also make use of shared tables.

In MediaWiki core, shared tables mainly rely on this Setup.php hack turning the table name into an alias via LoadBalancer::setTableAliases(). That's probably not possible to port to the virtual domain mechanism (we could use $wgVirtualDomainsMapping as the place to declare shared tables but the way that configuration gets used would differ from all other virtual domains), short of rewriting all queries with a join that involves both non-shared and shared tables. So maybe this task is not feasible after all.

Another option would be to deprecate without replacement, and create a small authentication extension that uses a shared table for passwords and emails, like CentralAuth. That and the user group part of T359116: Split up CentralAuth into smaller extensions would cover 99% of $wgSharedDB use cases, I think.

Pinging MediaWiki-Engineering to decide on how to procede with this. The idea sounds good, but there are questions about migrationg existing installations and how this would interact with CentralAuth.

@daniel Did you get an answer? MWI is part of MWE so I'm unsure whether you meant MPT or MWE. It got moved back to MWI, so I'm guessing something was said or decided?

In T355376#10082288, @Krinkle wrote:

@daniel Did you get an answer? MWI is part of MWE so I'm unsure whether you meant MWT or MWE. It got moved back to MWI, so I'm guessing something was said or decided?

No, I think this got stuck. Also, the only person on MWI really into this stuff is Aaron. Perhaps this would be a good topic for next week's Principal's office hours?