Last modified: 2013-09-25 14:38:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29002, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27002 - Completely de-couple the DB name
Completely de-couple the DB name
Status: NEW
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 26994
  Show dependency treegraph
 
Reported: 2011-01-28 00:49 UTC by Mark A. Hershberger
Modified: 2013-09-25 14:38 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mark A. Hershberger 2011-01-28 00:49:15 UTC
This is related to bug#26994 where Brion says:

> If the mapping of '''site key name''' <-> '''database name''' can be
> abstracted, this at least some of that may become easier.
Comment 1 Brion Vibber 2011-01-28 01:02:40 UTC
For comparison, here's how we do it in StatusNet:

* Each site has a 'nickname' used as an internal identifier, which never changes. This is used in multi-site data structures such as job queues.
* Local configuration, or a 'status_network' table for multi-site farms, can provide additional mapping between nickname, database hostname & database name, and domain name or URL path
* domain names or URL paths are used as the primary user- and admin-visible identifier for choosing which site to work with (via vhost on web or -sidenti.ca parameter on command-line scripts)

So to handle the Wikimedia-style cases, a central site mapping table might list for each row at *minimum*:

* database name ("enwiki")
* site family ("wiki"/"wikipedia")
* language/section subkey ("en")
* hostname ("en.wikipedia.org")

If we're actually using a mapping table instead of trying to manually break apart or build up from prefix/suffixes all the time, that might actually be plenty.

That would allow continuing to use the dbname as an internal key, while allowing language codes or domains to be altered.

However, in places where we expose db names (such as cross-wiki user management), we should consider displaying and selecting from canonical hostnames ('en.wikipedia.org') or language+family ('en.wikipedia') as a UI-friendly form, so that things that look like they don't match are no longer an issue.
Comment 2 Krinkle 2011-01-28 10:25:12 UTC
This sounds a lot like Toolserver's wiki database. Which is one of the reasons cross-wiki tools are relatively easy to make there.

A wikified dump of that MySQL table can be seen here:
https://wiki.toolserver.org/view/Wiki_server_assignments

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links