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
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
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
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
When I4764c1c78 switched from being run during read-both/write-new to
write-both/read-old, we should have also removed the code that
blanked/deleted the old rows. That was done for the main migration, but
was overlooked for log_search.
Bug: T215464
Change-Id: Icbba54dbd57fe0fa07ea0f6dcdde30089f067ace
This way it can be subclassed in extensions, like AbuseFilter
(Ic755526d5f989c4a66b1d37527cda235f61cb437).
Bug: T188180
Change-Id: Idf320232011c72e39267b1f3c39848aea35d37fe
So the conditional check should by default return $this->mDb if it's not
null, so, the else seems not to be needed(?). If we have a database handle
to process the current batch, $this->getDB() will return IMaintainableDatabase
but if it's not available (null), a call to $this->getDB() will return an
instance of \Wikimedia\Rdbms\Database is returned instead.
In accordance with the documentation (phpdoc), update the method getUserDB()
to be compliant with callers return type.
Change-Id: I95f3407dd2ffe8e4a1ad7a70be86b6cf3b65ff50
WikiExporter allows streaming mode, using unbuffered mode on
the database connection. We are moving away from this technique.
Instead, do multiple normal queries and retrieve the
information in batches.
Bug: T203424
Change-Id: I582240b67c91a8be993a68c23831c9d86617350e
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
This is mainly for the benefit of authentication extensions which
all need similar functionality for removing local passwords on a
wiki where local authentication was used for a while but has been
disabled, but can be used directly to just indiscriminately remove
the passwords of all users.
To test the change without irreversibly locking out users, an
option is provided to make the password invalid in an
easy-to-reverse way.
The immediate use case is I974184899c33.
This patch also introduces the maintenance/includes directory
to hold PHP files which are not executable scripts themselves.
(Previously such files had a .inc extension, but that is so PHP4.)
Bug: T57420
Change-Id: If7207b80a2c8374e90182e0b09d8f76ee94264b0
