As well hard-deprecate RevisionStore::listRevisionSizes.
It was marked as @deprecated, but the release for the
deprecation was not specified. Let's say it's 1.35.
Additionally, in order to avoid temporary code duplication,
listRevisionSizes now uses getRevisionSizes and ignores the
database object injected into it. This is ok since we're
hard-deprecating the method and all the usages have been
removed.
Bug: T246284
Change-Id: Ifad1c25a0af892b88fce492b2d34c8cf71279b70
Notably:
* In ApiManageTags, I used a switch instead of a dynamic function name,
so that the call graph will be correct.
* In ApiImageRotate, checkTitleUserPermissions() has always returned
void, this was an error introduced in 4e6810e4a2
Change-Id: Iea22616b8e7e2e0cc804619a54f8690898b2cb82
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
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.
So ensure the user names passed to the database are actually strings.
Bug: T240808
Change-Id: If2bca6ab9faa5b50516e47f06b0b26b3648e4cbf
In several places, we're including rc_timestamp or other fields in a
query selecting on rc_this_oldid because there was historically no index
on the column.
The needed index was created by I0ccfd26d and deployed by T202167, so
let's remove the hacks.
Bug: T139012
Bug: T239772
Change-Id: Ic99760075bde6603c9f2ab3ee262f5a2878205c7
When converting a Title object into a string for user or user talk
namespace the gender information are needed.
This patch set improves performance on wikis with gender distinction
like dewiki or ruwiki by combining the fetch of the information into one
query and avoids a query per unique user name.
It also avoids false results for request with apihighlimit, because the
apihighlimit with 5000 is higher than the query max limit of the
GenderCache with 1000
Bug: T200238
Change-Id: Ibe0561b210dbeb654117dad777e839640f51b4e4
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
For some unknown reason, when the `actor` table has few enough rows (or
few enough compared to `revision_actor_temp`) MariaDB 10.1.37 decides it
makes more sense to fetch everything from `actor` + `revision_actor_temp`
and filesort rather than fetching the limited number of rows from
`revision_actor_temp`.
We can work around it by telling it to not reorder the query, but then
(unlike in I9da981c0) we also have to reorder it ourselves to put
`revision_actor_temp` first instead of `revision`.
Bug: T221511
Change-Id: Ic63875b26a051a2da58374d5d76c95a6fa8ecc8e
Remove many references to database fields rev_text_id and ar_text_id,
which are being retired as part of MCR Schema Migration.
Some references remain, and will be removed under other patchsets
or other tasks.
Bug: T198341
Change-Id: Id044b8dcd7c9d09d5d6037eb732f6a105933f516
When querying by user name or actor ID, the partitioning on the
'contributions' replicas makes things worse rather than better.
Bug: T216656
Change-Id: Ib4caf19d8fad64c527dee99667e425fd3e4b1a16
This was originally a global search and replace. I manually checked all
replacements and reverted them if (due to the lack of type hints) either
null (that would be 0 when counted) or a Countable object can end in the
variable or property in question.
Now this patch only touches places where I'm sure nothing can break.
For the sanity of the honorable reviewers this patch is exclusively touching
negated counts. You should not find a single `!== []` in this patch, that
would be a mistake.
Change-Id: I5eafd4d8fccdb53a668be8e6f25a566f9c3a0a95
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
MCR deprecated the Revision class in favor of the broadly similar
RevisionRecord, and more interestingly added the concept of multiple
content "slots" to revisions.
Thus, prop=revisions, prop=deletedrevisions, and so on gain a parameter
to specify which slots are wanted. When this new parameter is not
specified (and any content-related props are specified), a warning about
the legacy format will be issued.
The rest of the modules just needed to call methods or use constants on
RevisionRecord instead of Revision. ApiQueryDeletedrevs wasn't touched,
since it has been deprecated since 1.25 anyway.
This also updates a few non-query modules that don't depend on details
of editing, diffing, or viewing MCR revisions that haven't been figured
out yet.
Bug: T200568
Change-Id: I1327d1784f5cedb006cd74df834cf9a560a77a5d
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
