simetrical@svn.wikimedia.org wrote:
Revision: 30877 Author: simetrical Date: 2008-02-12 20:11:58 +0000 (Tue, 12 Feb 2008)
Log Message: ----------- Remove inexplicable $nt->isContentPage() check for rendering link colors in makeLinkObj(). I don't know why there should be any difference, and there isn't for the other methods of rendering links.
"Stub"ness isn't meaningful for, say, user or talk pages. Being short isn't a crime there.
-- brion vibber (brion @ wikimedia.org)
On Feb 12, 2008 4:01 PM, Brion Vibber brion@wikimedia.org wrote:
"Stub"ness isn't meaningful for, say, user or talk pages. Being short isn't a crime there.
I see your point. Actually, it seems the general logic does this too, although I didn't see where, so I introduced an inconsistency rather than removing it. I'll partially revert this (so the redirect class is kept, but the stub class not).
On Feb 12, 2008 4:41 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Feb 12, 2008 4:01 PM, Brion Vibber brion@wikimedia.org wrote:
"Stub"ness isn't meaningful for, say, user or talk pages. Being short isn't a crime there.
I see your point. Actually, it seems the general logic does this too, although I didn't see where, so I introduced an inconsistency rather than removing it. I'll partially revert this (so the redirect class is kept, but the stub class not).
Oh, wait, it's done in Linker::getLinkColour() itself already. The extra check was just there to avoid a database query if it was unnecessary, which now it never is anyway. So everything is correct as it stands, unless someone wants to get militant about that extra query (which should be easy to fix . . . maybe I'll do so now).
On Feb 12, 2008 4:46 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
unnecessary, which now it never is anyway. So everything is correct as it stands, unless someone wants to get militant about that extra query (which should be easy to fix . . . maybe I'll do so now).
Actually, not so easy to fix, exactly, at least not if memcached is used. We're using LinkCache to fetch the article ID, so that can't be easily rolled up into the same query. Some custom code would have to be written, and it would still add a query on average unless it stored the redirect status/length/etc. in memcached too. The major effect here seems to be category links at the bottom of articles, which are the only uses of makeLinkObj() on article views I can see that are relevant (stuff like interwiki links won't run the query anyway). Maybe this part should be reverted after all, and the functionality kept only for the Parser code, unless someone wants to do some efficiency work.
Simetrical wrote:
On Feb 12, 2008 4:46 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
unnecessary, which now it never is anyway. So everything is correct as it stands, unless someone wants to get militant about that extra query (which should be easy to fix . . . maybe I'll do so now).
Actually, not so easy to fix, exactly, at least not if memcached is used. We're using LinkCache to fetch the article ID, so that can't be easily rolled up into the same query. Some custom code would have to be written, and it would still add a query on average unless it stored the redirect status/length/etc. in memcached too. The major effect here seems to be category links at the bottom of articles, which are the only uses of makeLinkObj() on article views I can see that are relevant (stuff like interwiki links won't run the query anyway). Maybe this part should be reverted after all, and the functionality kept only for the Parser code, unless someone wants to do some efficiency work.
LinkCache queries can most certainly be rolled up into the same query. $wgLinkCacheMemcached was a failed experiment which should not be used by anyone, and certainly isn't used by us. It can be removed at any time.
-- Tim Starling
On Feb 12, 2008 8:37 PM, Tim Starling tstarling@wikimedia.org wrote:
LinkCache queries can most certainly be rolled up into the same query. $wgLinkCacheMemcached was a failed experiment which should not be used by anyone, and certainly isn't used by us. It can be removed at any time.
But LinkCache caches by means other than memcached. It also uses a member variable cache. So it would still mean extra queries. Of course, if it caches the links' existence, maybe it could cache their color too . . .
wikitech-l@lists.wikimedia.org