This patch exists to see if CI passes with
$wgMultiContentRevisionSchemaMigrationStage set to
SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW.
NOTE: verify that $wgMultiContentRevisionSchemaMigrationStage
is explicitly set toSCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD
in production config (T197816) before merging this.
Bug: T198561
Depends-On: Ib718868d2c768b6ea851355eef047bc0e6593495
Change-Id: I15989adae2b5916577d164c50d7da88774e49324
Call the RevisionInsertComplete from RevisionStore for now, so extensions
that still rely on this hook don't break when more code uses RevisionStore
instead of Revision.
This specifically avoid breaking EventBus and Translate when If610c68f491
is merged.
Change-Id: I3356c8250d7934e0089d4627fdebddf7983f194f
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
This commit removes Revision::getRawUser(), Revision::getRawUserText(), and Revision::getRawComment(). All three were deprecated in 1.25 and are only used in unmaintained extensions.
Bug: T61113
Change-Id: I729985b791df89bc7e577fb823e647c48549e637
This introduces a convenience method for constructing a blob address
from a text ID. It's the inverse of SqlBlobStore::getTextIdFromAddress
Change-Id: I31b3ee5e40185c754fb2c119eb5edc50b903f5dc
This should have been done long ago. Now it is being done.
This also changes ar_text_id to NOT NULL, since it should never be null
anymore, and DEFAULT 0 in preparation for MCR stopping writing it.
Bug: T33223
Change-Id: I18f1c740b7537c7dc3cfeba9b241d0a9f31caa34
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This allows CommentStore to be added to MediaWikiServices
without the need of an aditional Factory.
This change includes a compatability layer to allow the behaviour
from 1.30 to continue to be used while deprecated.
CommentStore::newKey has been deprecated.
Keys are now passed into the public methods of CommentStore
where needed.
The following CommentStore methods have had their signatures changed
to introduced a $key parameter, but when used in conjunction with
CommentStore::newKey behaviour will remain unchanged:
* CommentStore::getFields
* CommentStore::getJoin
* CommentStore::getComment
* CommentStore::getCommentLegacy
* CommentStore::insert
* CommentStore::insertWithTemplate
Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
Lets not depend on the big blob that is RevisionStore.
Try to bind to the nice interfaces that we have where possible.
In the future RevisionStore should be split up further into
it's individual interfaces.
It looks like there are some more methods which should be moved
to both RevisionLookup and RevisionFactory.
See draft:
I214c5952d4a0fad55ff4116e90eab9ac3ba54fd3
Change-Id: I8df61374e24abcf4a7e38e53647489b8ecc1fd77
In the context of WikiPage->doEditUpdates(), when $revision->getContent()
returns null, $this->prepareContentForEdit() fails because it expects
something that implements 'Content' as its first argument but null is given.
This problem happens during Flow beta feature opt-out. I hope
this logging is not too spammy and helps shed light on the Flow
problem.
Bug: T184670
Change-Id: If06b8fda3657cae2eb23821f35e5b87919ceb615
For backwards-copatibility, we need to be able to construct a Revision
object even for bad page IDs.
Bug: T184689
Change-Id: I18c823d7b72504447982364d581b34e98924b67f
The Revision class used to just return null if size or hsash were unknown
and could nto be determined. This patch restores this behavior by
catching any RevisionAccessExceptions raised by RevisionRecord when
failing to load content.
Bug: T184693
Bug: T184690
Change-Id: I393ea19b9fb48219583fc65ce81ea14d8d0a2357
RevisionStore::newNullRevision must be passed a Title object when
being used, passing null will result in a fatal.
Title::newFromID can return null, so check and return null early if we
have no Title object.
Also use Title::GAID_FOR_UPDATE for a higher chance of getting a Title.
Prior to the Revision overhaul newNullRevision would have always done a
select from master, it is documented as accepting $dbw and also passed
FOR UPDATE as an option to selectRow.
Bug: T184687
Change-Id: If1f99d091ab9cd37d514a4f4cbf3c28b64426cb7
This is a partial revert of a revert that reverted a fix believed to
have had its underlying issue fixed in:
https://gerrit.wikimedia.org/r/#/c/400577/
The compat layer (Revision), now passes a Title object into the
RevisionStore, and this title is used to construct the Record and
also any new Revision objects.
Bug: T184559
Bug: T183548
Change-Id: Id073265c173f60aa8c456550fdb4bb5196013be8
In Revision::getKnownCurrent, fail early when Title::newFromId returns
null to avoid an uncatchable fatal error being triggered.
RevisionStore#getKnownCurrentRevision requires that the title parameter
be an instance of Title.
This follows on from Ia4c20a91.
Change-Id: I9bddafcc5df630d1dff1e2526194186cab7097e5
The $title param was added as part of
Ieabca1cf157fb667c75fc907b9da2917f71c61b3 and is not yet used
by any code.
The underlying issue with title fetching in RevisionStore has been fixed
in commit 4de36baa63
I15e4663902e2cbfe15b0da2e46449330e313bd0d
This patch removes the param that is not needed, but adds duplicate
logic to fetch a Title object to pass into the Revision object that
is created.
This logic is pulled directly from
RevisionStore::newRevisionFromArchiveRow.
Change-Id: I60568b8ffd22d5e3f861c03b4b8ef14332e9015b
This reverts commit a760526bb4.
This is a PARTIAL revert and the changes to the follwing methods remain:
- Revision::newFromArchiveRow
This is no longer needed as the underlying issue has been fixed
in commit 4de36baa63
I15e4663902e2cbfe15b0da2e46449330e313bd0d
Change-Id: I3e0ae29e62d59bcb4be871ef5b389a673ce8f103
This reverts commit 7bfb4f1951.
and 56b7ba03a2
This is no longer needed as the underlying issue has been fixed
in commit 4de36baa63
I15e4663902e2cbfe15b0da2e46449330e313bd0d
Bug: T183505
Change-Id: I194a558625d15fd4f7929e363557847f8bebde4f
This allows Revision::getRevisionText to get
a different BlobStore instance when $wiki is passed in
restoring the behaviour for $wiki before the MCR Revision
overhaul patch was merged.
Ia4c20a91e98df0b9b14b138eb4825c55e5200384
Bug: T183634
Bug: T183631
bug: T183583
Change-Id: Ib0949454e9a003c2965adc1aab38e31fcf121afe
If the title is not passed in as a param (already known) then select
it in Revision::newFromId instead of waiting for it to be selected
further down the tree.
This means that we can use the same Title object to pass into the
RevisionRecord as well as our legacy Revision object.
The selection chooses either a slave or master depending on
recent writes.
This logic used to be in Revision::getTitle and also in
Revision::newFromConds which was called by newFromId
Bug: T183505
Change-Id: I9cf4ce2c3c86d6bf979a3c88eb423b942b9a1ba4
This method used to overwrite attributes, then passed to
Revision::__construct
RevisionStore::newRevisionFromArchiveRow instead overrides row field
names
This patch adds a conversion for the one field that we need to care
about which is 'page' -> 'page_id'.
After looking through the usages in core and extensions it looks
like this will also fix a bug in the following classes which also
passes in 'page'.
- RevDelArchivedRevisionItem
- RevDelArchiveItem
Bug: T183564
Change-Id: I6a472b93663a0599abb55453c6939463ff56275d
When the title is already known use it.
This is similar to the issue fixed in
I714ee391caac9bc56ce4c037967e424b44d9c2fe.
As of this patch all methods within RevisionStore
that call getTitle internally also have an option
to pass in an already known Title object.
Bug: T183548
Change-Id: Ieabca1cf157fb667c75fc907b9da2917f71c61b3
This is a re-submission of I4f24e7fbb68.
As a first major step towards Multi-Content-Revisions (MCR),
this patch turns the Revision class into a legacy proxy for
the new RevisionRecord and RevisionStore classes.
Backwards compatibility is maintained for all but some
rare edge cases, like constructing a completely empty
Revision object.
For more information on MCR, see
<https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions>.
NOTE: once this is merged, verify create/delete/restore cycle on beta,
ideally with emulated replication lag.
Bug: T174025
Change-Id: Ia4c20a91e98df0b9b14b138eb4825c55e5200384
This reverts commit 9dcc56b3c9.
With this patch applied, newly created revisions are sometimes not found
just after submitting an edit, until replicas have caught up.
Our best theory is that it somehow interfere with ChronologyProtector,
but we don't have a good idea how.
Also, as legoktm mentioned, the commit message is terrible and needs fixing.
Change-Id: Idf3404f3fa8f8d08a7fb2ab8268726e2c1edecfe
The expected behavior for a null-edit is that the cache gets fully
purged as if another edit has happened, without actually inserting
a new revision into the database. Old implementation was to create
a new Revision instance, copy some of the private instance properties
from the old Revision instance, and skip database insertion. This
method is, unfortunately, prone to errors, as hooks and parsers
expect the given revision data to be equal to whatever the latest
revision is in the database, including timestamp and edit summary.
An alternative solution would be to maintain a method that copies
all the needed data from one revision to another; however, the extra
maintenance cost would be that it would be annoying to maintain it.
This implementation simply reuses the old Revision instance given
by the caller (WikiPage::doEditContent), as it is the latest
revision that hooks and parsers expect.
This patch fixes the error where, after null-editing, the
revision-related magic words, such as {{REVISIONDAY}}, are changed
to the values given by the null edit, instead of the latest revision.
Old behavior was caused by the parser parsing with incorrect
revision data.
Deprecate Revision::setUserIdAndName. It was a hack added in
147f79e for the same bug, addressing {{REVISIONUSER}}, but failed
to address the other magic words, including {{REVISIONDAY}}. I
failed to find any other usage of this instance method.
Bug: T135261
Change-Id: Ifce6a753effb98123574bff45ff59b5c9780f0c2
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
