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.)
--
Ilmari Karonen