brion@svn.wikimedia.org schreef:
Revision: 33381 Author: brion Date: 2008-04-15 18:11:28 +0000 (Tue, 15 Apr 2008)
Log Message:
Revert some chunks of r33133 and r33375:
- Let followRedirect() *always* work correctly by working from the article text.
- This ensures that we're not falsely looking up data from another version and that we're not missing interwik and fragment data.
Should clean up both bug 13754 (editing old version of redirect sometimes gives the target page text) and bug 13752 (bugs with fragments and probably interwikis in redirect target).
Haven't been able to repro 13754 at home though, so we'll see.
:O This is even crazier than r33375 (no insult to either committer): we have a redirect table to fetch redirect targets efficiently, and we're not actually *using* it anywhere. Bugs 13752 and 13754 should be fixable without reverting to the old (and inefficient) behavior (possibly with a schema change to the redirect table, as I suggested in response to r33375).
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roan Kattouw wrote:
:O This is even crazier than r33375 (no insult to either committer): we have a redirect table to fetch redirect targets efficiently,
No, we have it to make bulk queries efficient.
and we're not actually *using* it anywhere.
...except in all the bulk queries it was designed for...
Bugs 13752 and 13754 should be fixable without reverting to the old (and inefficient) behavior (possibly with a schema change to the redirect table, as I suggested in response to r33375).
...which would require adding interwiki and fragment field and god knows what else, and wouldn't actually make much of anything relevant more efficient, since individual lookups are fairly cheap.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber schreef:
Bugs 13752 and 13754 should be fixable without reverting to the old (and inefficient) behavior (possibly with a schema change to the redirect table, as I suggested in response to r33375).
...which would require adding interwiki and fragment field and god knows what else,
I don't really see what else: what other types of redirect do we have, besides section, interwiki and vanilla redirects?
and wouldn't actually make much of anything relevant more efficient, since individual lookups are fairly cheap.
I thought WMF wikis stored their text tables on separate servers? In that case, using the revision text would not only replace the SELECT on the redirect table by one on the page and revision tables (a join on two tables that are each larger than the redirect table, so it's very likely slower), but also cause more inter-server communications (probably even slower than a DB query). I know we're talking about milliseconds (or fractions of them?) here, but surely even those matter on large wikis (like WMF)?
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roan Kattouw wrote:
Brion Vibber schreef:
Bugs 13752 and 13754 should be fixable without reverting to the old (and inefficient) behavior (possibly with a schema change to the redirect table, as I suggested in response to r33375).
...which would require adding interwiki and fragment field and god knows what else,
I don't really see what else: what other types of redirect do we have, besides section, interwiki and vanilla redirects?
That's _probably_ it. :)
and wouldn't actually make much of anything relevant more efficient, since individual lookups are fairly cheap.
I thought WMF wikis stored their text tables on separate servers? In that case, using the revision text would not only replace the SELECT on the redirect table by one on the page and revision tables (a join on two tables that are each larger than the redirect table, so it's very likely slower), but also cause more inter-server communications (probably even slower than a DB query). I know we're talking about milliseconds (or fractions of them?) here, but surely even those matter on large wikis (like WMF)?
This lookup'll be dwarfed by the rest of the process of setting up MediaWiki, fetching the target page, possibly rendering it, and outputting a full page of HTML.
It's nice to shave off a little, but it's not the most critical code path.
- -- brion vibber (brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org