Document $parserCache, $title and $params for the constructor method
and minor typo fix newSpec() method.
Change-Id: I5968ee5bfe614da6f6dc8d7e0405799aa00b6127
Note that we will still be re-parsing either the old or the new
revision. Keeping the rendered version of the old revision cached
for a bit would be nice, but ParserCache currently does not
support this.
Bug: T205369
Change-Id: I86d26e494924eec24e7b1fb32c424ac1284be478
Using domains means thats JobQueueDB has the right value to use for calls
like LoadBalancer::getConnection(). The full domain includes the schema in
the case of Postgres. This makes calls to getConnection() less awkward by
not relying on the fallback logic in reallyOpenConnection() for null schemas.
Make getWikiIdFromDomain/isCurrentWikiDomain account for the schema if it
is both defined and is not simply the generic "mediawiki" schema MediaWiki
uses by default. If all wikis use the default schema, the wiki IDs can get
by with DB/prefix alone, which various config and methods may be built around.
Otherwise, the config callbacks must account for schema and the config must
include it in various wiki domain ID lists to properly disambiguate wikis.
Also, clean up SiteConfiguration::siteFromDB() since it is not meant
to handle schemas unless the callback method was taylored to do so.
Finally, add more comments to DefaultSettings.php about already existing
limitations of wiki domain IDs and their components.
Change-Id: I8d94a650e5c99a19ee50551c5be9544318eb05b1
Run updates for as many titles as possible and mark the job as failed
if a title is invalid. Set the error message used by the job executer.
Bug: T208147
Change-Id: I7f5fafe9439d8a7b45166515532075202af7d013
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
This assures that MergeableUpdate tasks that lazy push job will actually
have those jobs run instead of being added after the lone callback update
to call JobQueueGroup::pushLazyJobs() already ran.
This also makes it more obvious that push will happen, since a mergeable
update is added each time lazyPush() is called and a job is buffered,
rather than rely on some magic callback enqueued into DeferredUpdates at
just the right point in multiple entry points.
Bug: T207809
Change-Id: I13382ef4a17a9ba0fd3f9964b8c62f564e47e42d
The job is a warmup for the thumbnail cache, so loosing it is not
an issue. Most of the times thumbnail rendering fails because of
non-renderable or broken images, or because the thumbnail was
already created by a request. These conditions will not be fixed
by retrying, will only create more load on Thumbor.
Bug: T203135
Change-Id: Ib4640eb13ca93f7350ff0671fc559a76ebbbb1e9
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
So far, RefreshLinksJob re-generated the ParserOutput ba calling
Content::getParserOutput. This only works for the main slot. It
needs to instead get the parser output for all slots combiend,
by using RevisionRenderer and RenderedRevision.
Bug: T174035
Change-Id: I253dda26bfa5aefa15f8b1dcc59e69fc7e9d0cb7
Pages with many revisions experience transaction size exceptions,
due to archiving revisions. Use the job queue to split the work
into batches and avoid exceptions.
Bug: T198176
Change-Id: Ie800fb5a46be837ac91b24b9402ee90b0355d6cd
Use the given fname for all places.
The __METHOD__ inside the unlock closure would be shown as {closure} in
logs
Change-Id: I87ef26e893af858f58d1a77dcb2d8ee192456f5c
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
The prerendering job is an optimization, should
thumbnails fail to prerender, they will be reattempted
when a user views them again.
Bug: T203135
Change-Id: I2907bf10a2d22af9beffc530856f458a6adbfe45
Replaces Content::getSecondaryDataUpdates with
WikiPage::getSecondaryDataUpdates so that aggregation of
data updates from multiple page slots can be handled without
the caller having to care about it.
Also adds a WikiPage::updateParserCache method for convenience.
This is a temporary measure until DerivedPageDataUpdater
(or its replacement) can be exposed directly, at which point
the WikiPage methods will be deprecated.
Also fixes a parameter handling bug in DerivedPageDataUpdater.
Bug: T194043
Change-Id: Idbe7d582b49fcb7c90aea813773b7610ad44b1a8
For maintenance scripts it is usually harmful to throw an exception.
For jobs the exception was already caught and handled appropriately,
so this can continue as before. For DeferredUpdates it was extremely
harmful to throw an exception. So in the web case, reduce the timeout to
1s and continue as normal if the 1s timeout is reached. This allows the
DeferredUpdate to be throttled without being killed.
In the updater, increase the replication wait timeout to 5 minutes.
ALTER TABLE could indeed cause replication lag, but exiting the update
script with an exception will probably ruin your day. Update actions are
not necessarily efficiently restartable.
Do not call JobQueue::waitForBackups() when jobs are popped. Maybe it
makes sense to call a queue-specific replication wait function for
bulk inserts, like copyJobQueue.php, but doing it when jobs are popped
just makes no sense. Surely the worst that could happen is that the
queue would become locally empty? Removing this waitForBackups() call
avoids waiting for replication twice when JobQueueDB is used.
Bug: T201482
Change-Id: Ia820196caccf9c95007aea12175faf809800f084
While RefreshLinksJob is de-duplicated by page-id, it is possible
for two jobs to run for the same page ID if the second one was queued
after the first one started running. In that case they the newer
one must not be skipped or ignored because it will have newer
information to record to the database, but it also has no way
to stop the old one, and we can't run them concurrently.
Instead of letting the lock exception mark the job as error,
making it implicitly retry, do this more explicitly, which avoids
logspam.
Bug: T170596
Co-Authored-By: Aaron Schulz <aschulz@wikimedia.org>
Change-Id: Id2852d73d00daf83f72cf5ff778c638083f5fc73
PagedTiffHandler in particular will fail the generate a param string
for non-normalized parameters.
Also improve logging while we are at it.
Bug: T201305
Change-Id: I40e188f6525187303b6773990b887838b80630e0
We use $wgReadOnly for various reasons, one of which is to disallow
writes in the currently-non-active DC. However, we should allow the
readOnlyReason configuration variable to be available per JobQueue type
and have it the code respect that.
In our current set-up, we use JobQueueEventBus which ever only uses the
enqueue execution path and does not depend upon which DC it is executed
in, so this will allow us to enqueue jobs in both DCs.
Note that this is an alternative approach to the one outlined in
Ibbad6063b6b154d7f7d172c79f7be324bf80eb7e
Bug: T199594
Change-Id: I8f1a57a81ea11c1c587c0057fa8bb3454b0e0b56
After the switchover is completed we do not need this any more.
This class was marked deprecated as soon as it was created, so
removing it should be safe.
Change-Id: I3451a7a9d1e78bb2c7c988aeb1e3aac93bfc1b6f
Having a different ParserOptions for each content model isn't feasible
in an MCR world. And the only thing using this was Wikibase, which has
been fixed to do what it needs in a different way.
Bug: T194263
Change-Id: I01373b29ee25fa9346c6b0317155be4ccdc8c515
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
The replaces the hacky use of onTransactionIdle(), which no longer runs
immediately in explicit transaction rounds since d4c31cf841.
Also clarified TransactionRoundDefiningUpdate comment about rounds.
Change-Id: Ie17eacdcaea4e47019cc94e1c7beed9d7fec5cf2
Since it calls LBFactory::commitAndWaitForReplication, blocking for
an unknown amount of time, it is a bit "heavyweight" to be the sort
of quick update that uses onTransactionIdle().
Change-Id: Ic3476de5b61a7cd5f31ba487b186f9605a3b2774
The "AUTO" means AUTOCOMMIT, not "automatic transactions"/DBO_TRX,
which is basically the opposite concept. The new name does not
suffer from that ambiguity.
Keep the old constant as an alias for backwards compatibility.
Also remove LoadBalancer comment about non-existing field
Change-Id: I63beeb061fc9be73f320308e4d6393b58628b8c8
