Magnus Manske wrote:
Brion Vibber schrieb:
>Victor STINNER wrote:
>>I would like to know if someone is working on the bug "Article non
>>effaçable à cause d'un bug" (article which can't be removed because
of a
>>mediawiki bug). I heared that it should come from compression
>>trouble ...
>
>This will be fixed with some changes to the deletion backend in
>MediaWiki 1.5. (This isn't fully finished yet, I hope to get it done
>this weekend. Search the archives for my previous post on this subject.)
While you're at it, the current 1.5 page deletion doesn't work for older
MySQL versions that don't support the "DELETE tables FROM ..." syntax.
Fix it or require a certain miminum version?
Now fixed.
The more sweeping changes to using a rev_deleted flag aren't going to
get done in time for 1.5, so I've fixed up the existing system.
To summarize, here's how deletion used to work:
* The cur and old rows are copied in their entirety into archive rows.
Each row contains namespace/title, full text of the revision, and the
various revision metadata (user, comment, timestamp)
* Once copied, the cur and old rows are deleted permanently from those
tables.
* On undeletion, new old and cur rows are created with the information
copied out. The new page has a new cur_id key, and each revision has a
new old_id key which doesn't match what they had before.
* Block-compression broke this scheme since the scheme requires the
presence of related rows in the old table, referenced by original old_id.
Here's how it now works:
* The revision rows are copied in their entirety into archive rows, plus
the namespace/title. This does not include the text, but does include
the original rev_id number and a reference to the text row where the
text is stored.
* Once copied, the page entry and all revision rows are deleted from
those tables. The text rows are still present, but because they are not
attached to any revisions they will not be visible except through the
Special:Undelete interface.
* On undeletion, a new page entry is created with a different page_id
number. The revision entries are recreated _with_ their original rev_id
numbers, thus preserving permanent URLs across deletion/undeletion. The
text rows just stay where they were, but now are linked up to revisions
again and so are viewable.
* Block-compression should work happily with this scheme, since its
precious text rows are not touched.
Existing entries in the archive table should continue to work after the
upgrade; since they didn't include revision id number when they were
deleted, new revision numbers and text rows will be created for them if
they get undeleted.
Since it was the bit that removed the text entries that didn't work on
MySQL 3.x, it should now be compatible again.
I haven't actually taken out the warning about block compression,
though. Will find that next...
-- brion vibber (brion @
pobox.com)