This ensures that getSha1() and getSize() will return values consistent
with the revision's content, even if the content was changed indirectly
via the MutableRevisionSlots object returned from getSlots(), after
getSha1() or getSized() had already been called and the values cached.
While mechanism that triggers T239717 remains unknown, the root cause
appears to be that the cached hash and size may get out of sync with
the actual content of the new revision. The suspected mechanism is a
side-effect of a parser hook triggered during PST.
Bug: T239717
Change-Id: I0b61eb639282334df884313cdfbb3521fbfe7e88
This are fairly straight-forward shortcuts. Use the class directly.
Also remove comments about injecting the current time via callbacks
which is obsoleted by the wikimedia/timestamp now having support for
mocking the time, via Wikimedia\ConvertibleTimestamp::setFakeTime
or (subclass) MWTimestamp::setFakeTime.
Bug: T225730
Change-Id: I5b49f0a0f0ae2daca8f054243b1c4c0a94422653
These fields are passed to methods like LoadBalancer::getConnection() and are
already expected to be DB domains. Update various comments as well.
Fix a few minor IDEA warnings.
Change-Id: I7cf76700690aec449872a80d30b5ba540d2bf315
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
2018-10-09 10:22:48 -04:00
Renamed from includes/Storage/MutableRevisionRecord.php (Browse further)
