Support new block schema
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
2023-10-27 03:34:10 +00:00
|
|
|
<?php
|
|
|
|
|
|
|
|
|
|
namespace MediaWiki\Block;
|
|
|
|
|
|
|
|
|
|
use Wikimedia\Rdbms\IReadableDatabase;
|
|
|
|
|
use Wikimedia\Rdbms\SelectQueryBuilder;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Helpers for building queries that determine whether a user is hidden
|
|
|
|
|
* @since 1.42
|
|
|
|
|
*/
|
|
|
|
|
class HideUserUtils {
|
|
|
|
|
/**
|
|
|
|
|
* Select users that are not hidden
|
|
|
|
|
*/
|
|
|
|
|
public const SHOWN_USERS = 1;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Select users that are hidden
|
|
|
|
|
*/
|
|
|
|
|
public const HIDDEN_USERS = 2;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get an SQL expression suitable for use in WHERE clause which will be
|
|
|
|
|
* true for either hidden or non-hidden users as specified.
|
|
|
|
|
*
|
|
|
|
|
* The expression will contain a subquery.
|
|
|
|
|
*
|
|
|
|
|
* @param IReadableDatabase $dbr
|
|
|
|
|
* @param string $userIdField The field to be used as the user_id when
|
2024-04-09 03:26:02 +00:00
|
|
|
* joining on block. Defaults to "user_id".
|
Support new block schema
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
2023-10-27 03:34:10 +00:00
|
|
|
* @param int $status Either self::SHOWN_USERS or self::HIDDEN_USERS
|
|
|
|
|
* depending on what sort of user you want to match.
|
|
|
|
|
* @return string
|
|
|
|
|
*/
|
|
|
|
|
public function getExpression(
|
|
|
|
|
IReadableDatabase $dbr,
|
|
|
|
|
string $userIdField = 'user_id',
|
|
|
|
|
$status = self::SHOWN_USERS
|
|
|
|
|
) {
|
2024-04-09 03:26:02 +00:00
|
|
|
// Use a scalar subquery, not IN/EXISTS, to avoid materialization (T360160)
|
|
|
|
|
return '(' .
|
|
|
|
|
$dbr->newSelectQueryBuilder()
|
|
|
|
|
->select( '1' )
|
|
|
|
|
// $userIdField may be e.g. block_target.bt_user so an inner table
|
|
|
|
|
// alias is necessary to ensure that that refers to the outer copy
|
|
|
|
|
// of the block_target table.
|
|
|
|
|
->from( 'block_target', 'hu_block_target' )
|
|
|
|
|
->join( 'block', 'hu_block', 'hu_block.bl_target=hu_block_target.bt_id' )
|
|
|
|
|
->where( [ "hu_block_target.bt_user=$userIdField", 'hu_block.bl_deleted' => 1 ] )
|
|
|
|
|
->caller( __METHOD__ )
|
|
|
|
|
->getSQL() .
|
|
|
|
|
') ' .
|
|
|
|
|
( $status === self::HIDDEN_USERS ? 'IS NOT NULL' : 'IS NULL' );
|
Support new block schema
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
2023-10-27 03:34:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Add a field and related joins to the query builder. The field in the
|
|
|
|
|
* query result will be true if the user is hidden or false otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Note that a GROUP BY option will be set, to avoid duplicating the result
|
|
|
|
|
* row if the user is hidden by more than one block.
|
|
|
|
|
*
|
|
|
|
|
* @param SelectQueryBuilder $qb The query builder to be modified
|
|
|
|
|
* @param string $userIdField The name of the user_id field to use in the join
|
|
|
|
|
* @param string $deletedFieldAlias The field alias which will contain the
|
|
|
|
|
* true if the user is deleted.
|
|
|
|
|
*/
|
|
|
|
|
public function addFieldToBuilder(
|
|
|
|
|
SelectQueryBuilder $qb,
|
|
|
|
|
$userIdField = 'user_id',
|
|
|
|
|
$deletedFieldAlias = 'hu_deleted'
|
|
|
|
|
) {
|
2024-04-09 03:26:02 +00:00
|
|
|
$cond = '(' .
|
|
|
|
|
$qb->newSubquery()
|
|
|
|
|
->select( '1' )
|
|
|
|
|
// $userIdField may be e.g. block_target.bt_user so an inner table
|
|
|
|
|
// alias is necessary to ensure that that refers to the outer copy
|
|
|
|
|
// of the block_target table.
|
|
|
|
|
->from( 'block_target', 'hu_block_target' )
|
|
|
|
|
->join( 'block', 'hu_block', 'hu_block.bl_target=hu_block_target.bt_id' )
|
|
|
|
|
->where( [ "hu_block_target.bt_user=$userIdField", 'hu_block.bl_deleted' => 1 ] )
|
|
|
|
|
->caller( __METHOD__ )
|
|
|
|
|
->getSQL() .
|
|
|
|
|
') IS NOT NULL';
|
|
|
|
|
$qb->select( [ $deletedFieldAlias => $cond ] );
|
Support new block schema
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
2023-10-27 03:34:10 +00:00
|
|
|
}
|
|
|
|
|
}
|