Timwi wrote:
Rob Church wrote:
There's been some discussion on a development mailing list regarding the namespace selector in contributions pages, which is expensive due to our schema arrangement. [...] What is the point of per-namespace contribution feature on live site? What are the applications of it?
What is the point in that question? If it is so database-intensive that it needs to be taken down, then surely it should be taken down even if it is useful. Conversely, if it is not database-intensive enough to be a real problem, then surely it doesn't hurt to have it even if it isn't useful.
It may be in the between. Perhaps the load it causes might be just enough to make some other useful but nonessential feature infeasible with the current server resources. (Or maybe not, just speculating for the sake of it.)
Besides, it appears that few people have found a really good use for it; it can therefore be assumed that it will not be used very frequently, and therefore it will likely not have much database impact after all. :)
I certainly find it useful. And in any case, it can generally be assumed that if it's there, it will be used.
It's true that efficiently indexing that in such a way that page moves across namespaces remain O(1) is hard. However, it strikes me that, for most uses of that feature, we presumably aren't really interested in the current namespace of the page so much as in the namespace it was in when the contribution was named. If so, a simple solution presents itself: add a field to the revision table recording the _original_ namespace (and maybe pagename, while we're at it) of the revision as it was when it was created.
(The null revisions resulting from page moves should probably be considered to belong in the target namespace, especially since another revision is already created in the source namespace for the redirect.)