JobQueueGroup::get( $type ) returns a new object for each job type even
if it's the same class (default class). Also it builds different queues
and push them separelty a couple lines lower limiting the ability to
batch push them in the default job queue object.
Given that JobQueue cares about job types being the same as the class
type (which is important for JobQueueDB implementation), adding a config
option called typeAgnostic to ignore type mismatch in JobQueue
implementations that don't care about the type (like JobQueueEventBus)
Bug: T292048
Change-Id: I151f067ca94a985c816446b545921c387b083911
For both LinkTarget and PageReference, just extract
namespace and dbkey and pass those in the array
of parameters to Job::__construct().
Allows a bunch of simplification to WatchedItemStore.
Bug: T291531
Change-Id: Id150d0c62af38d4b3d17e5698866127c6e04717e
With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
Queries that query a value "1" are expected to return either
that "1" (possibly as a string), or false. It's safe to simply
cast this to bool and use it as it is.
Queries for COUNT(*) are expected to return that number,
possibly as a string. It's not possible for such a query to
return false. And even if, casting to 0 is fine.
I found an existing code style where the table name and the
"1" are on the same line as the selectField() method name, and
applied it to all similar queries.
Change-Id: I9453196281871c03ef03f653f43762eb9284342f
Also switch one use that we missed in the rebase.
Bug: T254646
Depends-On: I632610dec1aa6bb59af5423e6f86164fc791aadd
Change-Id: I9873c889f943fcbd7d867d534a7857f20ef0c5dc
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
This allows deferred update tasks to be constructed with a PageIdentity
rather than a Title instance.
Bug: T278459
Change-Id: Ifa2888fdef9ecc97f5bf09ae0b3fa7be48a0e9ef
This replaces JobQueueGroup::singleton and ::destroySingletons.
A JobQueueGroup service has been added to serve as convenience
getter.
Bug: T277648
Change-Id: Ic8709119773ab788a07531193dc65d418536eda2
LinksUpdate may encounter a non-existing page due to race conditions,
when the page has been deleted or renamed before the update is executed
or even created. We should log such incidents to detect anomalities,
but we should not crash hard.
Similarly, RefreshLinksJob should not attempt to run on a page that
no longer exists.
Bug: T281802
Change-Id: Ic73c3e339ff0478710bd57a9f707c1284dcce2d9
Follows-up bf8c90538d.
The RecentChangesUpdateJob class has two modes of operation, one for
purging RC rows, and one for updating activeusers.
The former did its delete query within the lock, the latter did not.
We think this is the reason the latter sometimes causes a deadlock.
Move it within the lock to attempt to mitigate this.
Bug: T255059
Change-Id: Idc076dca15f4ba2e0a3a8f89623cfbfc9c25b27e
