Last modified: 2011-03-13 18:06:03 UTC
Once a namespace is defined, the number assigned to it must not be changed if it contains articles. There is no infrastructure to handle namespaces appearing in a different order (such as from insertions or deletions). Changing the namespace organization is nontrivial, and made especially difficult because the namespace of a page is not treated as part of its name. Namespaces should probably never be assigned numbers. Their textual names reliably identify them; wikicode concretely defines which namespaces are in use. Since numerical namespaces are used nowhere in articles aside from the numeric {{ns}} directive, an article continues to refer to the correct location after organizational changes (though the database may connect the location to the wrong namespace). For example, suppose that namespaces A, B, and C exist, each containing a page named "article". In each namespace, "article" links to the "article" in the following namespace (with C linking to A). A ({{ns:0}}) A:article -> B:article (0:article -> 1:article) B ({{ns:1}}) B:article -> C:article (1:article -> 2:article) C ({{ns:2}}) C:article -> A:article (2:article -> 0:article) Suppose we decide A should be {{ns:1}} instead, and B should be {{ns:0}}. One would expect to find the following afterward: A ({{ns:1}}) A:article -> B:article (1:article -> 0:article) B ({{ns:0}}) B:article -> C:article (0:article -> 2:article) C ({{ns:2}}) C:article -> A:article (2:article -> 1:article) However, this is not the result. Here is the actual situation before the change: A ({{ns:0}}) 0:article -> B:article (0:article -> 1:article) B ({{ns:1}}) 1:article -> C:article (1:article -> 2:article) C ({{ns:2}}) 2:article -> A:article (2:article -> 0:article) After A and B are swapped, the database has lost the articles' names. A ({{ns:1}}) 1:article -> C:article (1:article -> 2:article) B ({{ns:0}}) 0:article -> B:article (0:article -> 0:article) C ({{ns:2}}) 2:article -> A:article (2:article -> 1:article) Now B:article links to itself, and C:article links to the original B:article. Examining [[Special:Whatlinkshere]] shows that the database thinks they are linked in the correct numerical order.
Unfortunately, namespaces can have multiple names (one localised, one canonical); we could just use the canonical name in the database, though. OTOH, this would probably be a lot less efficient (checking $ns=="Image" is always going to take longer than $ns==6) for seemingly little gain. The obvious solution would appear to be don't change the order of the namespaces; ever. If a new namespace is required, shove it on the end; if one is removed, just never use that number again. The only thing wrong with this "solution" that I can think of is conflict between "custom" and "official" namespaces (e.g. when upgrading). In that case these should be given arbitrarily high namespace numbers - e.g. 1001, 1002, 1003, etc (for all I know, they already are!)
There is no reason to change the numbers. If it were necessary, the article database can be re-adjusted with a few queries.
(In reply to comment #2) > There is no reason to change the numbers. If it were necessary, the article > database can be re-adjusted with a few queries. > Exchanging two namespace numbers is equivalent to a variety of potential problems, including adding, removing, or replacing namespaces; creating new sub-namespaces similar to the "talk" namespaces; or merging databases with different numbers for the same namespace (or the same number for different namespaces). If namespaces were not numbered at all, there would be no need to readjust databases. Why should the user have to learn SQL and the underlying database structure to change the part of the page title before a colon? Why store a numeric namespace for each page when SQL could store each page in a namespace table? If namespaces were separate tables, metadata about the namespaces and their talk pages would not need to be hardcoded, localized namespace aliases could be stored in the database itself, and a lot of code could be simplified.
If namespaces had a separate tables for metadata, a numeric row ID would be the natural way to index them... just like now.
Comment #3 contains a series of examples of why this could be a problem, so let's think about each of them: * adding, removing, or replacing namespaces As I mentioned in comment #1, we should (and easily can) assign numbers to namespaces in such a way that numbers never conflict: only create new namespaces with higher numbers than all existing ones, and if a namespace is removed from the code, don't reuse that number. I'm not sure what "replacing" would mean; if you mean renaming, then this doesn't need to touch the database, for the precise reason that the namespace will still have an identifying number. * creating new sub-namespaces similar to the "talk" namespaces Although currently each namespace X has an associated talk namespace X+1, this could equally be represented by {X, X+10}, or by a list of arbitrary associations (either in the PHP code, or in the database). If the namespaces were textually, rather than, numerically, stored, such a list of associations would have to be defined anyway. * merging databases with different numbers for the same namespace (or the same number for different namespaces) Surely this should never happen, because if a namespace exists, it has a unique number, and if a namespace has a unique number, it exists. If there were a need to split or merge namespaces, this would require processing the database, however it was you'd labelled those namespaces. * Why should the user have to learn SQL and the underlying database structure to change the part of the page title before a colon? To simply give a new name to an existing namespace, you can change the appropriate localisation string. If you need to assign all pages in a given namespace to a new namespace, this is equivalent to moving all those pages en masse, which would need the construction of an appropriate SQL query. Note that in the example in comment #0, the problem is not that the namespaces are behaving unexpectedly, but that the links on the pages haven't been changed: "A:article" has been effectively moved to "B:article", but its text still contains "[[B:article]]". This is still the case whether the move is considered as [ns:0 -> ns:1] or as [ns:"A" -> ns:"B"]. If you want the namespace called "A" to remain called "A", but think namespaces should have no numeric value, what is it you are intending to change?
