Use ObjectFactory specs for collation classes
Avoid the language construction in the factory class,
make it a detail of the implementation of each class
Follow-Up of Ifc96f851e6091ce834dbaf0e91695c648a42169c
Bug: T286079
Change-Id: Ib581f64aec8619986fb8dd49ceee0524d59a1b84
Currently the updateCollation maintenance script throws an error
when ran, as it calls MediaWikiServices before it's initialized.
See the phab task for more details.
Bug: T246127
Change-Id: Ib9d6b485b55760897ff5152b5d6f22b0d6a36daa
MWNamespace::clearCaches() has been removed entirely, along with the
$rebuild parameter to MWNamespace::getCanonicalNamespaces(). The rest of
MWNamespace is deprecated.
Diff best viewed with -C1 so git notices that NamespaceInfo is a copy of
MWNamespace.
Depends-On: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
Depends-On: Ib3c914fc99394e4876ac9fe27317a1eafa2ff69e
Change-Id: I1a03d4e146f5414ae73c7d1a5807c873323e8abc
The most notable removal is done in the orphans script. This code was
really never used. Brion introduced it in 2005, already disabled.
I have all the respect for what Brion did. I just think it does not make
much sense to keep code around for so long if it does not work anyway,
and must be rewritten from scratch anyway now that we have multi-content
revisions and such.
Change-Id: I4e8050929f90e44a6e6051bf938993a8b0cdf649
This method returns the value used as cl_type for category links that
are "from" pages within the namespace, and is added to avoid duplication
of code across a few classes.
Change-Id: I4e55932a5a27858cfedb12009b455fcd02f9b5df
Maintenance::commitTransaction is calling waitForReplication already.
No need to wait a second time, hopefully the lags are 0 already.
Change-Id: Id457ed2cdd6bfd9663665ba0cd5c4e3dd640b738
Now prints the number of rows that would be modified after each batch.
This is meant to be useful for sysadmins who are upgrading the ICU
library on their servers and wondering whether they need to run
`updateCollation.php --force` to avoid ordering problems.
Change-Id: Ie0c37d279d4e5bc1c69408d714246625c81c70fa
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
Currently if you run updateCollation.php in dry-run mode, it ignores
the other parameters and doesn't give you a row estimate. Now it
will behave the same as an actual run (just without making any
changes to the database).
Change-Id: I25a9751d8ab7554e7975e5f08122dd1ddaaf40a7
2000 writes per wfWaitForSlaves() seems a bit high. There was a
report of this script causing some slave lag when being run.
Note that, the amount of time between wfWaitForSlaves() was
previously increased in r97146.
Bug: T58041
Change-Id: I07a29499775a17255865f25e6b9f1058f898193b
jcrespo reported a lag spike at the very beginning of running this
script. I'm guessing that's due to counting how many rows in
categorylinks to give the progress bar. Since we only need a
rough estimate for the progress meter, make that query run on
a slave. Also add a wfWaitForSlaves() immediately after it for
good measure.
Bug: T58041
Change-Id: I3cba392f0013fcb2ef86803632e2d9b1b88b3b29
We want to update categories in order, to minimize disruption
to users. Previous indexes required a filesort to do this, which
exploded things on large wikis. See bug for details
Bug: T58041
Change-Id: Iee6cd997ff87a313a46fda19d8ab063d0fed8ce8
Using the cl_sortkey index instead (to reduce disruption to a live
site), as currently implemented, seems to have two serious problems:
* MySQL / MariaDB filesorts all rows that "sort above the given row
[the last row of the previous batch]", not just a single category
at a time until the row limit is reached.
* The current approach to pagination is broken in that it does not
work with ENUM columns such as cl_type, causing 'file' rows to be
skipped, or rows of any type to be repeated. See T119173.
This reverts part of commit a43f751cf6.
Bug: T58041
Change-Id: I619564e85b2122f249bdacc45d547b9ce1b3beb5
Add transaction methods to complement getDB().
This makes it easy to grep for direct begin()/commit()
calls to IDatabase by having script use their own
wrapper. Maintenance scripts are one of the few places
that can (and need to) use begin/commit instead of the
start/end atomic methods.
Eventually, there should be almost no direct callers
and those methods can be made stricter about throwing
errors on nested calls.
Change-Id: Ibbfc7a77c0d2a55f7fc2261087f6c3a19061e0aa
In some cases the constructor will work, but trying to access first
letter data will raise an exception, breaking all category pages.
Bug: 46615
Change-Id: I77de040f97080653fe0d1734d38490eaa2d322db
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Sorry, forgot that method was not in the base class, and I had only tested with uca based collations. This breaks on uppercase type collations.
This reverts commit 6eb84144df
Change-Id: Ib7b9597ff842a76185ba5c153922834ffb741237
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
Apparently cl_timestamp=cl_timestamp is a workaround for obscure
behaviour of the timestamp type in MySQL
Change-Id: I803f20bcf4e28e8e2833a07bcf00e7edc00ad84b
Have updateCollation.php order by cl_to, so that each category is
updated all at once. This minimises the time during which a category
will appear to be incorrectly sorted, while the maintenance script is in
progress.
Mark the cl_collation index as needing deletion, it was always pretty
pointless. You can't do much better than a full table scan when you're
changing the collation value on a wiki.
Increase the batch size since the lack of a cl_to,cl_from index means
that it will have to filesort each category. A larger batch size means
less sorts. As noted by Liangent on bug 45970, you can't order by
cl_sortkey since that will change during execution.
Also fix an inappropriate use of $wgMiserMode and remove a no-op from
the SET clause of the UPDATE.
Very lightly tested.
Change-Id: I19bc8d6701f5f78040aa9c521427ac98ef488d89
Variables in classes should be declared using public $foo
instead of var $foo for various reasons. As we require PHP 5.3
we don't have to take care about that PHP4 left over, but can
get rid of it in favour of the more clear and better readable
public.
See also: http://php.net/manual/en/language.oop5.visibility.php
(Divided into several commits to keep reviewable)
Change-Id: Ic723d0347ab2e3c78bc0097345c68bbee3dc035a
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
