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
When it's only reading, it should only rely on read methods.
Update a few callers in ChangeTags and ActorStore-related code while
at it.
Bug: T326274
Change-Id: I78dd5cbef2d480d23ba2955555421224770d474b
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
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
The order $userId, $name, $actorId is more consistent
with existing order of arguments in UIV constructor,
User::newFromAnyId etc. Even though it's not as logical
as placing the primary key argument first, it's more practical.
Change-Id: Ic36c0ee451cf6825976e374f0c2f721085c0a507
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
