Changed some inserts to use multi-row insert for small performance
benefit where possible and not already used.
InsertQueryBuilder does not return a value, deprecated since 1.33
Bug: T353219
Change-Id: I2380ebc8ec8db178dd790247aefbdd798b6d62ff
Why:
* Following T345578, the ActorStore throws an error on
attempting to create an actor whose name is their IP address
if temporary accounts are enabled.
* For the specific case of importing old revisions, we need to
be able to create new actors whose name is their IP address,
while still generally disallowing it.
What:
* Add $allowCreateIpActors flag to ActorStore, and check for
it during actor name validation.
* Set the flag from ActorStoreFactory::getActorStore depending
on whether temporary users are enabled.
* Add ActorStoreFactory::getActorStoreForImport, which sets
flag to true.
* Add RevisionStoreFactory::getRevisionStoreForImport, which
uses getActorStoreForImport. Use this from classes handling
imports, so that IP actors can always be created.
* Add $forImport flag on ActorMigration, since RevisionStore
uses an actor store obtained via ActorMigration.
Bug: T354207
Change-Id: I0715bd0d23089fd8156e579913e6e823089809be
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
Why:
There are extensions that need to check a handful of
users for temp-ness at once (such as GrowthExperiments).
This is not really possible as of now (it would be necessary
to call UserIdentityUtils::isTemp several times, which can get
slow for large bulks of users).
What:
Add TempUserConfig::getMatchPattern() that can be used
to generate a LIKE database condition.
While at it, this patch also adds named() and temp() to
UserSelectQueryBuilder.
Bug: T341389
Change-Id: I90b5c59462c5c98bf5dcf9fa15d20553ef6599a5
Code that needs to store an actor ID in the database to
represent a UserIdentity, or needs to construct a UserIdentity based on
an actor ID loaded from the database, should use the ActorNormalization
service.
Note: The getActorId() method is removed from the UserIdentity interface,
but all concrete classes continue to support it for now.
UsererIdentityValue::getActorId() is hard deprecated and should
be removed in 1.37. It always returns 0.
User::getActorId() is not deprecated at this point.
Bug: T274179
Depends-On: Id2b3ddf6a2a7cdf90f8936a69148d2cce6fde237
Change-Id: I9925906d11e47efaec3c1f48d5cb3f9896a982c1
Surprizingly, PHP treats string "0" as false, so user name "0"
was unconditionally rejected by ActorStore. Even more surprizingly,
we actually have an actor with user name "0" [1], so we need to
explicitly check for nulls instead of just checking for falsy.
[1] https://en.wikipedia.org/wiki/User:0
Change-Id: I535c2aee3e109c3f535e40b747a1c7e4508171cb
Replace UserIdentity::getUserId with ::getId
Add $wikiId = self::LOCAL as an optinal parameter to User and
UserIdentity
Bug: T275482
Change-Id: I44494845c469a14284c3e23cb620e5a7cbf59cd5
The findActorIdByName method is intended to be used when we need to
select by actor ID, but all we have is a user name. We can't use
findActorId(), since it requires a UserIdentity, which would needlessly
force us to look up a user ID, resulting in two queries.
Bug: T274179
Change-Id: I0e65d3258fd3d23ebff793ae04d59e027eb51fba
This introduces a specialized SelectQueryBuilder for
queries related to actor table. So far it's fairly basic,
but in future it is intended to grow.
This patch only introduces the new abstraction, using
it will be separated into separate patches.
Bug: T274223
Change-Id: Ibb1c58016e3956a46bfaf1a9f51f265114bb9ace
