Please group related methods instead of adding new at the bottom along with deprecated ones. Thanks.
Change-Id: Ie08500de8226e33d5fe4c8a2a95c6a23a550e6d1
When generalizing LinksUpdate to DataUpdate and introducing
WikiPage::getDeletionUpdates(), WikiPage::doDeleteUpdates()
was removed, even though it was still used by Title::moveToInternal().
This patch restores WikiPage::doDeleteUpdates(), using the
new logic based on WikiPage::getDeletionUpdates() to implement it.
Change-Id: I12a49d5ca3ccb6bb9cbb63dde436bcf2a7d8a985
This supercedes I6d03bf2a, using better names for the new classes and
incorporating the changes requested by Aaron.
This change introduces the base class SecondaryDataUpdate to be used for any
updates that need to be applied when a page is changed or deleted. Until now,
this was done by the LinksUpdate class for updates and WikiPage::doDeletionUpdates
upon deletion. This patch uses a list of SecondaryDataUpdates in both cases.
This allows extensions (e.g. via the ContentHandler facility, once that is in) to
easily specify what needs to be done when a page is updated or deleted in order to
keep any secondary data stores (such as link tables) in sync.
Note that limited transactional logic is also introduced, so SecondaryDataUpdate
can be implemented to only commit their changes if all updates were performed
sucessfully.
Patch Set 2: fixing some coding style issues mentioned by Nikerabbit.
Patch Set 4: some stuff I kept from the old LinksUpdate class needs cleanup,
but might break extensions when changed. Marking as todo for now.
Patch Set 5: fixed misnamed member in LinksDeletionUpdate (thanks Aaron).
Change-Id: Ibe3e88fadd8c1d4063cf13bb6972f2a23569a73f
In WikiPage.php:
* Added WikiPage::$mDataLoadedFrom to store the source of the data used to load the state of the object and four new WikiPage::DATA_* constants for its possible values.
* Added WikiPage::convertSelectType() to convert 'fromdb', 'fromdbmaster' and 'forupdate' to the new WikiPage::DATA_* constants.
* Added $options to WikiPage::pageData(), WikiPage::pageDataFromTitle() and WikiPage::pageDataFromId() so that the "FOR UPDATE" option can be passed to DatabaseBase::select().
* Added new possibility "forupdate" to WikiPage::loadPageData() load the data from the master database using SELECT FOR UPDATE; this avoids to have to do this by LinkCache (via Title::getArticleID( Title::GAID_FOR_UPDATE ) )).
* Changed WikiPage::doDeleteArticleReal() to use this new feature so that all the data stored in WikiPage is up-to-date.
My point is also to deprecate the loading using SELECT FOR UPDATE in Title and remove LinkCache::forUpdate() at some point (there are still one usage in Title::moveTo(), two other in UploadFromUrlTest plus some in extensions).
In EditPage.php:
* Don't call WikiPage::clear() after fetching informations from master, this destroys all we work we did to get the correct data.
* Reload the whole data from master using SELECT FOR UPDATE directly in WikiPage and not only in Title. The problem was that before, the up-to-date information was only available in Title and not in WikiPage.
Consider the following sequence from a MySQL prompt (where both revision 1 and 2 belong to page one, revision #2 being the current one):
mysql> UPDATE page SET page_latest=1 WHERE page_id=1;
mysql> COMMIT;
// Now grad the edit form for page #1 from the web and do some changes
mysql> BEGIN;
mysql> SELECT page_latest FROM page WHERE page_id=1 FOR UPDATE;
// Now submit the web form
mysql> UPDATE page SET page_latest=2 WHERE page_id=1;
mysql> COMMIT;
Before you ended-up with a "edit conflict" form with revision #1's text being displayed as current text (even if the texts are mergeable), due to the fact that
in the submit request the WikiPage object was loaded at the moment where page_latest was 1 (certainly due to MySQL's "consistent read" feature) making the
"UPDATE page SET ... WHERE page_id=1 AND page_latest=1" query of WikiPage::updateRevisionOn() return zero row, and thus WikiPage::doEdit returing a fatal Status object with message "edit-conflict".
Now the SELECT FOR UPDATE is done in the WikiPage, meaning that the object has the correct data and EditPage will correctly try to merge the revisions (and show the correct edit conflict if needed).
Change-Id: Ic4878ddb4dd96432b7ecaf43f9f359458d966999
* Separated the last part of WikiPage::loadPageData() into loadFromRow() to put database access and object loading into separate methods (and also for consistency with other classes)
* Added WikiPage::newFromRow() to be able to get a WikiPage object from an already-existing database row
* Modified WikiPage::newFromID() to do a single database request to get all the necessary data and make it use the new newFromRow() method
Change-Id: I2db423f2dba10cc3db4f4b2e7a7b9d99cd114f33
* {{REVISIONID}} and related variables are no longer blank after doing a null edit
* {{REVISIONID}} and related variables are no longer blank after calling action=purge&forcelinkupdate
* Pass the User object from WikiPage::commitRollback() to WikiPage::doEdit()
* Do the edits with 'Maintenance script' user as other maintenance scripts instead of 127.0.0.1
* Call Title::isValidRedirectTarget() in case of special page instead of checking only for Special:Userlogout
* Refactor the code a bit to be more readable and remove unneeded nested conditions
* WikiPage::$mCounter is now marked as protected
* Call WikiPage::loadPageData() from WikiPage::getCount() if the count is not set intead of loading the page_counter field only
Title objects are meant to be dumb value objects; we shouldn't add to their internal state like this, but should be working to remove the bits already in there like the article ID.
Preloading information like this can make sense, but probably belongs in WikiPage, not Title.
* Added Title::load() to factorise common code that load member variables instead of having each accessor doing it own loading system for its related member variable
* Removed usage of LinkCache::addLinkObj() to do the database query and do this directly in Title::load(). This allows to select the complete database row and populate all member variables; previously, requesting a field not stored in LinkCache (using getCount(), getTouched() or isNewPage()) results in two database query, one to load LinkCache data and the second to load the requested field; now there'll be only one query.
* Added Title::FIELD_IN_LINKCACHE and Title::FIELD_NOT_IN_LINKCACHE to specify whether the requested field is stored in LinkCache or not. LinkCache will be used if possible (i.e. Title::FIELD_IN_LINKCACHE is passed), otherwise a DB query to select the complete row is issued.
* Made Title::loadFromRow() save the row to LinkCache if possible.
* Added $wasFromMaster parameter to Title::loadFromRow() to tell that method whether the row was loaded from the master database or not and pass it from WikiPage::loadPageData()
* Added Title::GAID_USE_MASTER in addition to Title::GAID_FOR_UPDATE to get the row from the master database without having to do a SELECT FROM UPDATE query
* Added Title::selectFields() method to return the fields to select to given Title::loadFromRow() (and methods using it such as Title::newFromRow()) a complete row
* Made Title::$mCounter private since it has only been added recently (in r105790)
* Mark the object as loaded if Title::resetArticleID() is called with as new ID as 0
* Removed $oldFashionedRestrictions parameter from Title::loadRestrictions*(); the only extension using it is LiquidThreads and it's using Title::newFromRow() to create the Title object, so the field is already cached (and this even allows to cache that field when there's no row for that page in the page_restrictions table)
* Also reset $mTouched and $mIsNew members on resetArticleId() calls
* Updated FakeTitle a bit
* Use WikiPage::doEditUpdates() and WikiPage::onArticleDelete() to do updates instead of reimplementing the whole thing in Title::moveTo(); avoids some bugs since the implementation differs from the one from WikiPage (notably the page and article count). This adds some more cache clearing, but they are needed depending on parameters (e.g. if the redirect is not created).
* Moved WikiPage::estimateRevisionCount() and WikiPage::isBigDeletion() to Title and marked those WikiPage methods as deprecated (only call in extensions removed in r107385)
* Show an error message when deleting a page to move another one in Special:MovePage and the deletion fails due to permissions errors (previously the form would simply show again)
* Cache the result of Title::estimateRevisionCount() since it's called two times when showing the deletion form and the user doesn't have 'bigdelete' right (one for the permissions check and the other when showing the number of revisions)
