Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
For every table except revision, the use of ActorMigration was "soft
deprecated" in 1.34. Now, hard deprecate it.
Bug: T278917
Change-Id: I63d26d13026214d84b6b94f06b4ad0d2362d97ed
AbuseFilter needs a class which is almost identical to core's
ActorMigration, so I split out the generic facilities into
ActorMigrationBase, leaving the bits specific to core in ActorMigration.
I changed the way fields and tables are specified so that it's easier to
override in subclasses.
Proper injection of ActorStoreFactory in
ActorMigrationTest::testGetWhere() was necessary to avoid a test failure
due to a teardown issue.
Bug: T278917
Change-Id: I3a6486532f2ef360d1fd01b3a609de71d412f739
ActorNormalization should only be used in contexts where a DB connection
is already being used, or at least easily available.
Bug: T276986
Change-Id: Ie8aadaffa4a30e63fcad0502d45b8ec364fc79ef
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The ActorNormalization factory methods create
UserIdentityValue from the database rows, either via
fields of a joined table, or via a row from actor table.
They assume that the actor_id exist and throw othervise.
ActorNormalization is a storage-layer service providing
access to finding and acquiring actor_id.
The UserIdentityLookup methods do not instantiate new actor
on demand, they just find an appropriate row in the actor
table and return the result.
Bug: T272689
Depends-On: I74d81f3f0233efb17fc8df5178e4c477cc669c6f
Change-Id: Icfa1daca960c696a8cef8adab5eab53985802858
This was almost always happening already but handling it in
ActorMigration is less fragile.
Also recover some lost tests.
Bug: T272225
Change-Id: I24c82cfbd40595e79f64c6b0441c2cf789cfbbff
This builds on top of Urbanecm's patch, now also covering the case
where the actor ID does not exist in the target DB, but does exist in
the local DB.
Bug: T260485
Change-Id: I2336954c665366a99f9995df9b08071d4de6db79
(cherry picked from commit ca4094db9e7f6f5e330d89db6bf70a8af48e1561)
In ActorMigration::getInsertValues, when creating a User object, calling
User::getActorId triggers a call to User::load, which ignores
the database passed to getInsertValues, meaning incorrect actor IDs
are returned.
To ensure that the correct (foreign) database is used, try
to get the actor ID from the correct database within ActorMigration
service, and if that fails, let User class handle the actor ID creation.
Todo notes are left in the patch to fix the issue properly,
by making User object wiki-aware.
Bug: T260485
Change-Id: Iaa886a1824e5a74f4501ca7e28917c780222aac0
Small addition to ActorMigration.php doc comment
to make it clear that classes should use this
instead of directly accessing db tables
Change-Id: Ibad838d35ea87f85966cda2b210f18196d50f844
Some callers, when provided an invalid user name, will wind up passing
null or false. This raises a PHP warning and winds up treating it as the
empty array. In this case, it seems best to DWIM and continue that
behavior without the warning.
At the same time, let's more explicitly reject other values for $users.
Bug: T239772
Bug: T207217
Change-Id: I6027481f6cad222369911d5053fecc06c92b36ea
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
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
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
