These not only make the code more robust, but also help a lot when
writing unit tests: if a method is return-typehinted and its class is
mocked, the mock method will automatically return a mock of its declared
return type. Otherwise it will return null, and developers are forced to
manually mock the method if the return value is used by the SUT in a way
that doesn't accept null.
Depends-On: I628fcb1807133390c7b9b47984f512f5b1ae58d0
Depends-On: I7080bc505f5838b2f51a368da562104e206063b0
Change-Id: I59068cfed10aabf6c6002f9e9312a6ef6e7e9441
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
In this patch I replaced RevisionStore::$dbDomain to
RevisionStore::$wikiId, RevisionRecord::$mWiki to
RevisionRecord::$wikiId and changed all hierarchies
and tests accordingly
Bug: T272901
Change-Id: I439515cfb6aa8a8697c2a5a0458ec8925522363a
As we convert the RevisionRecord to using Authority,
we no longer need Title instances, so we can convert
that to PageIdentity.
Ideally, we'd part away from using Title at all, but:
1. For foreign wikis PageIdentity has stronger validation,
so calling PageIdentity getId() on Title will break things.
There's still a lot of code depending on lax Title guarantees,
so we keep it.
2. A lot of code still depends on Title, so we try to pass it
through even if we don't nesessarily need to, to save cost
on recreating it later on.
Bug: T271458
Depends-On: I287400b967b467ea18bebbb579e881a785a19158
Change-Id: I63d9807264d7e2295afef51fc9d982447f92fcbd
By definition, MutableRevisionRecord object is supposed to have
several of its internals mutated during its lifetime and so it has
over dozen setters and its users will usually call several also
at any given time.
Currently to properly use it, the variable holding the instantiated
object needs to be repeatedly used for every thing to set, because
none of the setters return value.
This can be simplified by allowing method chaining.
This will have no effect to existing code and no any compatibility
problem but will greatly simplify writing new code/and fixing old one,
helps in writing more flowing expression and eliminates the need to
repeat the variable name for each and every setter call.
This patch only affects the setters (15 in total).
Change-Id: Idc9c1dc66bf6898add04540e6f471d0ccd18aca7
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
This annotates classes that can safely be instantiated by
extensions, per the Stable Interface Policy.
Bug: T247862
Change-Id: Ia280f559874fc0750265ddeb7f831e65fd7d7d6a
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)
