Hi!
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 ...
I can help you, I know a lot of langages (assembler, Python, PHP, C++, etc.) and have long experience in programmation.
Bye, Haypo
Victor STINNER wrote:
I can help you, I know a lot of langages (assembler, Python, PHP, C++, etc.) and have long experience in programmation.
En anglais, on dit "programming", pas "programmation".
Wikipedia est écrit en PHP, donc il doit être possible pour toi de nous aider. Voir sur tes premiers pas ici: http://meta.wikimedia.org/wiki/How_to_become_a_MediaWiki_hacker
Bonne chance! Timwi
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.)
-- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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?
Magnus
Magnus Manske wrote:
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?
It doesn't work _at all_ at the moment as it will delete the wrong items if any.
-- brion vibber (brion @ pobox.com)
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)
wikitech-l@lists.wikimedia.org