When there are more files as the batch size,
the script loops as the where condition is not changed.
Bug: T401088
Change-Id: Ic52ea24de0bd68db9e7d84e2f1b1067b20c2836d
(cherry picked from commit 9a162bff8add74a1b797cf0769b8601d440cc231)
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
Maintenance class provides a method for getting a fresh reference
of the MW services container instance. Let's make use of these in
maintenance scripts now that we have it.
NOTE: There are still some static methods like in refreshLinks.php
that makes use of services that we can't use this method for now.
Change-Id: Idba744057577896fc97c9ecf4724db27542bf01c
Using a php parser written on top of ANTLR4, done semi-automatically.
I checked everything and made adjustments.
Bug: T311866
Change-Id: I6150c6909bce8f3dbd745a26380cc0af9d9c547f
Until I70473280, integer literals were always quoted as strings, because
the databases we support all have no problem with casting
string-literals for comparisons and such.
But it turned out that gave MySQL/MariaDB's planner problems in some
queries, so we changed it to not quote actual PHP integers.
But then we run into the fact that PHP associative arrays don't preserve
the types of keys, it converts integer-like strings into actual
integers. And when those are passed to the DB unquoted for comparison
with a string-typed column, MySQL/MariaDB screws up the comparison while
PostgreSQL simply throws an error. Sigh.
This patch adds string casting to direct uses of array_keys() to supply
values for such query conditions. It doesn't change uses where the field
being compared is a numeric field.
If anyone knows of a good way to find indirect uses of array_keys() for
passing as $conds to IDatabase methods, please do so!
Change-Id: Ie72ee33437d492904e1495b3f4ebb1fcf0118f49
The following function are set to public in the parent class and cannot
have another visibility in subclasses
Maintenance::__construct
Maintenance::execute
Maintenance::getDbType
Maintenance::validateParamsAndArgs
Maintenance::setDB
Change-Id: I0cd6514642d479aca20f1221bf673b0713c21631
* That sometimes triggered a filesorts when the title for the
inequality has certain (seemingly long) values.
* Also made the continuation queries use > instead of >=.
Change-Id: I912df77ad43f025918e52d1494300d487a9deea1
