Last modified: 2008-09-21 01:21:09 UTC
The protection log for [[Mozilla Firefox]] in English Wikipedia includes the following: 2007-12-04T22:08:11 Cbrown1023 (Talk | contribs | block) changed protection level for "Mozilla Firefox" (Firefox has been protected for nearly a week now and, looking at the discussion page, it seems like one of the edit warriors has agreed to walk away. Could it be unprotected now? -MBlume 05:39, 4 December 2007 (UTC) (restoring semi-protection) [edit=autoc) This log entry was apparently truncated because of excessive length. The truncation cut off the details of the protection level, making it impossible to parse the log entry to determine the protection level. Also, the expiration date is completely removed. If a protection log entry is too long, it should be trimmed before the restriction level and expiration date are appended.
This would be because log_comment is only a VARCHAR(255), however increasing this to the next biggest level (BLOB\TEXT) would use a hell of a lot of resources. Perhaps if the different sections were stored in different columns the situation could be helped, however the easiest solution would be to disallow or trim comments that add up with the other parts of the summary to a value higher than 255 characters.
Created attachment 4795 [details] trim protection log comments
Created attachment 4796 [details] trim log comments The first patch changed the order of the page history entry slightly, update patch to keep the same output format
Those details really should use log_params
Fixed in r40713. This is not retroactive.
(In reply to comment #1) > This would be because log_comment is only a VARCHAR(255), however increasing > this to the next biggest level (BLOB\TEXT) would use a hell of a lot of > resources. Not enormously. It would force temporary tables to disk and maybe have a few other consequences, but this column is normally only included in result sets, so it shouldn't be the end of the world. We should switch log_comment and rev_comment to SMALLBLOB at some point, especially for i18n purposes -- some languages might have half the number of characters available and this isn't reflected in the field's maxlength, which goes by characters instead of bytes. But those are big ALTERs and so no one seems to be interested in doing them.
