Rather than containing the category's name, the cl_to field should contain the category ID as defined in the category table. This would make moving categories (GSoC project) much easier and doesn't store the category name in two places.
BTW, has the category table been built on WMF wikis yet?
Version: 1.13.x
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T15326 Things that could use a category table (tracking) | |||
| Declined | None | T15579 Categorylinks table should use category ID rather than category name in cl_to field |
ayg wrote:
Yes, it has, long ago. A major reason for this change would be a much smaller (therefore faster) categorylinks table.
The link tables specify text rather than IDs for rename safety... the links are created by text in the article (and any templates it uses, and any parser functions it calls, etc), which would not be changed by any alteration to the target page.
Things get ugly when you have to try to figure out how to go back and change texts. :)
ayg wrote:
Conveniently, categories can't be renamed, so that's not a big issue at present. ;) Any implementation of this big a change should wait until an implementation of category redirects/renaming, which could easily require changes to categorylinks too. It would be fairly annoying to change the schema in such a major way *twice*, not just for whoever does the alters but also for extension authors, etc.
Per @brion, link tables represent secondary data (derived data) based on the wiki pages and their meta data. Wiki pages use category links based on titles, not IDs. Categories could be deleted, re-created, renamed, but that doesn't change that the pages continue to point to a category name.
If and when meta data starts being stored separately with a layer of indirection in the interface (e.g. categories are identified by an id with a display title that is only that, a display title), this will happen naturally, so there's no need for this task to exist.