From the see also task:

In T50625#1125429, @coren wrote:

The database exists, and is enduser-provided. Nothing for ops to do here.

In T50625#3132467, @bd808 wrote:

This is quite a feat of thread necromancy you have performed @Dispenser. It looks like you are probably reporting two separate and distinct issues at once:

• Missing toolserverdb_p view
• Stale information in the backing tables populated by the toolserverdb tool which @jkroll, @Nosy, and @Tobi_WMDE_SW maintain.

For the first issue, I don't see anything in T50625#488761 that tells us how @coren created the view in the first place, but I have a sneaking suspicion that is was a manually created view rather than something that is automatically maintained. This is probably how the view ended up disappearing. The easiest thing to do today would probably just be to update any documentation to name the s51892_toolserverdb_p database itself rather than the view created alias.

For the second issue the toolserverdb tool maintainers will need to get involved.

@Dispenser can you provide a clear and actionable description of what you are hoping to see changed?

I hope to see a namespace table added to meta_p. And with more thought. Domain isn't needed, dbname should lose _p per Labs convention, and maybe a gender flag to distinguish Benutzer and Benutzerin depending on future MW plans. Here's what it is currently (note: MediaWiki and MediaWiki Diskussion):

SELECT *
FROM s51892_toolserverdb_p.namespacename
WHERE dbname LIKE "dewiki_p"
ORDER BY FLOOR(ns_id/2), ns_is_favorite DESC, ns_type, ns_name;

Like most things on meta_p, my own opinion is that this should go on production (and replicate to wikireplicas from there), maybe as part of handling better configuration management. It doesn't necessarily have to go into mysql, but it would be blocked by a better option than parsing configuration files.

In any case this is not a trivial thing to do and requires mediawiki experts input if done on production, or if there is already existing code, it would speed up its deployment (there is not non-public data preventing anyone from implementing this), current canonical data is on operations/mediawiki-config git repo.

It's kind of funny that MediaWiki has gone out of its way to abstract namespace names, using namespace IDs so that the namespaces can be localized or renamed somewhat easily and specifically not putting the namespace names into the database. And this effort and architecture gets immediately undermined by having people insist that the namespace names be shoved back in to a database.

Given the small amount of data, the typically easy workarounds (e.g., using {{subst:ns:4}} when posting to a wiki page), and the availability of this data via api.php, I'm not sure it makes sense to continue maintaining this database. There might be some value if we resume using clusters (e.g., 1, 2, 3), as finding which databases were in each cluster was never programmatically exposed elsewhere, as far as I know.

The namespacename database table in particular is basically a cache of https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases, which most applications could simply look at themselves or, if needed for performance reasons, could create their own small cache of just the data they need instead of using a shared cache.

I didn't know that was already available on production as an api. If that is the case, I would either reject this or have it with the lowest priority because:

if needed for performance reasons, could create their own small cache of just the data they need instead of using a shared cache

If you like you can shutdown the project.
Can anyone see who queries the DB to inform the users and then turn it off after a reasonable amount of time?