This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
It has been already announced: https://w.wiki/9DAX
Bug: T354194
Change-Id: Ic2357634b8385d65b55db2b557191419b06c40e0
Found via (?<!IDBAccessObject)::READ_
We are planning to deprecate and remove implementing IDBAccessObject
interface just to use the constants.
Bug: T354194
Change-Id: I89d442fa493b8e5332ce118e5bf13f13b8dd3477
Instead of calling self::READ_* on these constants, just directly call
it.
Since these classes are public and might be relied on directly in other
places, we can't remove the "implements IDBAccessObject" yet but we will
start doing that soon.
Bug: T354194
Change-Id: I3e26b9fc7f93efdfc55a1790a7cdfa5c0d562303
Turned out to be much easier to do than expected.
It's literally a reader, isn't it? This change will make it possible
to use the more narrow IReadableDatabase interface in many more
places in our codebases. Some additional changes had to be made in
this patch already (most notably in ActorStore) to make Phan happy.
Bug: T326274
Change-Id: I5a886ad741f3abeadf0242039bfcce266e9c086b
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 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
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
