Run CodeReview populateFollowupRevisions maintenance script on mediawiki wiki, so we can use the more efficient path searching :)
Version: unspecified
Severity: enhancement
Run CodeReview populateFollowupRevisions maintenance script on mediawiki wiki, so we can use the more efficient path searching :)
Version: unspecified
Severity: enhancement
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Catrope | T28529 Run CodeReview repopulateCodePaths maintenance script on mediawiki wiki | |||
Resolved | None | T25720 CodeReview doesn't show ancient revisions for a path |
Could you run this on your local DB and report the table size and #rows before and after?
See https://bugzilla.wikimedia.org/show_bug.cgi?id=23720#c7 for rough figures
Just re-ran it now after having updated to latest revisions
mysql> select count(*) from mw_code_paths WHERE cp_repo_id = 3;
+----------+
count(*) |
+----------+
1004172 |
+----------+
1 row in set (7.95 sec)
Seems ~double number of paths
This is normal behaviour.
The only thing sort of "preventing" us from us from running this, is the code not having been scapped live, allowing us to do somewhat more efficient SQL queries to do path searching, whereas before we're doing an SQL like which filesorts/temporary tables.
Which isn't great. So this changes it so we save all path fragments, and can do an equals, rather than like and other crappy stuff
So this goes through and repopulates the path list, to list all fragments as a separate row per path fragment for a revision commited
Noted as a scaptrap https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/79379#c13295
I'll need to do this some time before deployment, I guess.
(In reply to comment #8)
Should this depend on the 1.17 deployment? Or is this another deployment?
1.17, yes.
(In reply to comment #9)
(In reply to comment #8)
Should this depend on the 1.17 deployment? Or is this another deployment?
1.17, yes.
...although I guess it wouldn't hurt to do this earlier and get it out of the way.
It will obviously need a followup run later on, just to fully update the newer revs, but that really is a minor issue, and we can choose a rev list, so its not a big deal ;)
(In reply to comment #9)
(In reply to comment #8)
Should this depend on the 1.17 deployment? Or is this another deployment?
1.17, yes.
Are you going to push all the cr revisions post 1.17 into the 1.17 branch?
As I'm sure this was post branching...
And of course it needs running for all repositorys
(In reply to comment #12)
(In reply to comment #9)
(In reply to comment #8)
Should this depend on the 1.17 deployment? Or is this another deployment?
1.17, yes.
Are you going to push all the cr revisions post 1.17 into the 1.17 branch?
As I'm sure this was post branching...
And of course it needs running for all repositorys
It's post-branch? Awesome! Then I won't have to worry about it for another few weeks.