Last modified: 2011-03-13 18:06:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 702 - Namespace infrastructure cannot adapt to changing namespaces
Namespace infrastructure cannot adapt to changing namespaces
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Lowest major (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2004-10-12 19:39 UTC by Leah
Modified: 2011-03-13 18:06 UTC (History)
0 users

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


Description Leah 2004-10-12 19:39:28 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.
Comment 1 Rowan Collins [IMSoP] 2004-10-12 20:24:49 UTC
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!)
Comment 2 Brion Vibber 2004-10-12 20:31:53 UTC
There is no reason to change the numbers. If it were necessary, the article
database can be re-adjusted with a few queries.
Comment 3 Leah 2004-10-12 21:48:35 UTC
(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.
Comment 4 Brion Vibber 2004-10-12 21:50:21 UTC
If namespaces had a separate tables for metadata, a numeric row ID would be the
natural way to index them... just like now.
Comment 5 Rowan Collins [IMSoP] 2004-10-12 23:05:40 UTC
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?

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