| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
Change-Id: Ie225ebfc37c824e3167742137bbbc9f64aca5f5e
|
|/
|
|
|
|
|
|
|
| |
This reverts commit 2cdeb26d0c2bc6f3fb4d05d7b8b72c4a601b3da7.
Reason for revert: broke roughly all scripts extending LoggedUpdateMaintenance.
Bug: T246754
Change-Id: Icfe3da924c364b4b4f9286871aeb0aa9f1bbff1a
|
|
|
|
| |
Change-Id: I4c95f910993fffa060c2860847b8cfff1612ccf5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added:
- ContentHandlerFactory
Tests:
- PHPUnit
Changed
- Calls of changed and deprecated
- DI for some service/api
Deprecated:
- ContentHandler::* then similar to ContentHandlerFactory
- ContentHandler::getForTitle
- ContentHandler::$handlers
Bug: T235165
Change-Id: I59246938c7ad7b3e70e46c9e698708ef9bc672c6
|
|
|
|
|
|
| |
Column names or other sql fragments are strings, not integer
Change-Id: I7950b6e7ce4fa3b97c8b8ed55c8d7d0119eaac7e
|
|
|
|
| |
Change-Id: I90cfe8366c0245c9c67e598d17800684897a4e27
|
|
|
|
| |
Change-Id: I94a0ae83c65e8ee419bbd1ae1e86ab21ed4d8210
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Also move Benchmarker.php to maintenance/includes/ because
that file is not itself a benchmark, and that base class is
actually covered by tests and should remain included.
Change-Id: I4acd88242dde56a884d319dfc141a3511a8221a3
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that the request to get the max pages or revs for
building our ETA info was going to any random db rather than one
designated for dumps. These are the world's shortest queries
so it shouldn't matter performance-wise but it's nice to be
consistent.
Bug: T143870
Change-Id: I0fff8b366e935c0d15295ca766981af4d5f87634
|
|
|
|
| |
Change-Id: I44c82fbe65e1d002803ce065df6563f06dd39cd4
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
All uses were checked with codesearch, and the visibility was chosen as
strict as possible.
Change-Id: I56666299cc04ccc418e05949422876583982eb3c
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was wrongly assuming that if the description started with
a dollar sign, that that first word would be the variable name
it was documenting, thus leading to some oddly documented
class members, such as from:
> SimpleCallbacks.php:
> /** @var (string|string[])[] $_GET/$_POST data */
Fix this by capturing the first word and actually comparing
it to the variable name we're about to document.
Keep the overall behaviour the same as before, that is,
if the description does indeed start with the correct variable
name, then don't modify it in any way (already covered by test).
Change-Id: I48ed20cf75f146a30d5976fcad3a72d5a9a4906b
|
|
|
|
|
| |
Bug: T232104
Change-Id: I591f44678cff4adb8863ce5c6ce231a8d3e162d7
|
|
|
|
|
|
| |
This avoid global state
Change-Id: Id67d07597159a0bd2721a381775230c3cd1d5509
|
|
|
|
|
|
| |
Bug: T231636
Depends-On: I50377746f01749b058c39fd8229f9d566224cc43
Change-Id: I2cd24e73726394e3200a570c45d5e86b6849bfa9
|
|
|
|
|
|
| |
Bug: T231636
Depends-On: I6e5fba7bd273219b1206559420b5bdb78734aa84
Change-Id: I50377746f01749b058c39fd8229f9d566224cc43
|
|
|
|
|
|
| |
Bug: T231636
Depends-On: I58e67c2b38389df874438deada4239510d21654f
Change-Id: I6e5fba7bd273219b1206559420b5bdb78734aa84
|
|
|
|
|
|
| |
Bug: T231636
Depends-On: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
Change-Id: I58e67c2b38389df874438deada4239510d21654f
|
|
|
|
|
|
|
|
|
| |
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
|
|
|
|
|
| |
Bug: T228772
Change-Id: I0d9448b2565481f61d927b2d58f44bddbf358ed8
|
|
|
|
| |
Change-Id: I8944a052f51a1941ad3b76a40fc9c46d1363c426
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Ide4518292bd9392d09f701b2c301673687d19f3b
|
|/
|
|
| |
Change-Id: Idc2980c05873c428fb5ffa6ab89f723d33217a8e
|
|
|
|
|
| |
Bug: T174031
Change-Id: I2717019ea7efe36694bd2b2fba4dc2952a987cfc
|
|
|
|
| |
Change-Id: I705a3fab4a6b151b81b45a3e2d7559f554986378
|
|
|
|
|
|
|
|
|
|
| |
Previously it was fixed to be in a certain location relative to
the MW instllation; this would allow the path to the script to
be passed in as an argument. If not, the script reverts to its
previous behavior.
Bug: T204962
Change-Id: Ib9fcf073332670149544d56e375541d014600371
|
|
|
|
|
| |
Bug: T182814
Change-Id: I53746333fe3c1cdc357bf46d71a351231a845e2f
|
|
|
|
|
| |
Bug: T164262
Change-Id: I9b3c54503dd9ad193af7765459613a7e73ffbb45
|
|
|
|
|
|
|
|
|
|
|
| |
We don't alter the db query for this, but throw away the extraneous
rows before doing any processing on them whatsoever.
Use of the DumpNamespaceFilter comes too late to avoid processing
for each revision done in XmlDumpWriter::writeRevision.
Bug: T220940
Change-Id: I9cb30ce612d862d97d96720ac68ff2327409f485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The query in question is, generically,
SELECT ls_value, ls_log_id, actor_id
FROM log_search LEFT JOIN actor ON (ls_value = actor_user)
WHERE ls_field = 'target_author_id'
ORDER BY ls_value, ls_log_id
LIMIT 100;
The intention is that it'll pull out 100 rows from log_search using its
primary key, and for each of those 100 rows find the actor_id for the
referenced user_id (using the actor_user index) if an actor ID exists.
The twist comes in the fact that ls_value is a string-type column while
actor_user is an integer-type. MySQL doesn't usually care, but other DBs
do so we have to cast one into the other.
Currently the code is casting actor_user to a string. But that means the
DB can't use the index on actor_user to find the one matching row,
instead it needs to scan the whole table.
The fix is simple enough: instead of casting actor_user to a string,
cast ls_value to an integer. That allows the actor_user index to be used
as expected.
Bug: T215525
Change-Id: I2f7a6ba9fd537336594088a0281a62ea5601cd59
|
|
|
|
| |
Change-Id: Ic08210a8cd394f6ad49673a2d2e4800e6bcf2989
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Broken in I979b6c8f0a72bc1f5ecce1d499d3fdfa0f671588
Bug: T174031
Change-Id: I494fe7578f936a2316c27f9c419e981055c38ed4
|
|/
|
|
|
|
|
|
|
|
| |
This code is functionally identical, but less error prone (not so easy
to forget or mix these numerical indexes).
This patch happens to touch the Parser, which might be a bit scary. We
can remove this file from this patch if you prefer.
Change-Id: I8cbe3a9a6725d1c42b86e67678c1af15fbc5961a
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: T214293
Change-Id: I98e26b833df473bbeb3dc1b881f428174d776b64
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During migration, RevDel may wind up being used on items where an actor
has not been assigned yet. The code creating log_search rows for
target_author_actor needs to take this into account.
Also, to clean this up on Wikimedia wikis, I've added code to
MigrateActors to delete these rows before (re-)migrating log_search
and a --tables option so a re-run can skip trying to process all the
already-processed tables (cf. T188327#4892827).
Bug: T215525
Change-Id: Ica15e2e30445e23761e6d3d6405b3eb39a086161
|
|/
|
|
|
| |
Bug: T174031
Change-Id: I979b6c8f0a72bc1f5ecce1d499d3fdfa0f671588
|
|
|
|
| |
Change-Id: I56f42ef2d2e9b4f3c23e1e93d1a4d3db64f16de7
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is, in theory, a loophole that can not only cause such code to
consume suprising amounts of memory and runtime. It can also create
suprising results. For example, an input like
-param="might contain a = char"
might result in a cut-off value.
Not so much of a problem in a maintenance script. But still good
practice, I find.
Change-Id: I14fb278e6fdb61d0c486ca7e23229851ea479408
|
|
|
|
| |
Change-Id: I00b30466fa6044988768493586993c3db253c975
|