Last modified: 2012-01-12 10:59:31 UTC
How are we to read through these messages now that they have suddenly doubled in width? Adding ar_deleted field to table archive......already have ar_deleted field in archive table, skipping new field patch. Adding ipb_deleted field to table ipblocks......already have ipb_deleted field in ipblocks table, skipping new field patch. Adding fa_deleted field to table filearchive......already have fa_deleted field in filearchive table, skipping new field patch. Adding ar_len field to table archive......already have ar_len field in archive table, skipping new field patch. Adding ipb_block_email field to table ipblocks......already have ipb_block_email field in ipblocks table, skipping new field patch.
(In reply to comment #0) > How are we to read through these messages now that they have suddenly doubled > in width? Use a wider console window
Instead of going from ... category table already exists to Creating category table... ...category table already exists. Skipping create table category why not something that says the same thing and not be extremely wordy, like: ...category table already exists, not creating.
The "Creating category table..." is useful in case it died between the two ellipsis. You usually don't need to read all of them (unless you want to), and there is a --quiet switch to only show errors.
In the past it was quite easy to see which ones changed something and which ones didn't. Not any more. And one wants to see which ones changed something, along with errors.
(In reply to comment #1) > (In reply to comment #0) > > How are we to read through these messages now that they have suddenly doubled > > in width? > > Use a wider console window This is not a helpful suggestion.
I have reverted change r103691 with r103892. update.php output is back :-)
Created attachment 9525 [details] update.php output still contains about 1/5 of the long message lines Thanks however about 1/5 of those long lines are still in the output. Many of them clearly just need the part before the dots chopped in order to match the same style of meaning as the other lines. A few of course cannot just so simply be chopped and still make sense though.
(In reply to comment #7) > Created attachment 9525 [details] > update.php output still contains about 1/5 of the long message lines > > Thanks however about 1/5 of those long lines are still in the output. > Many of them clearly just need the part before the dots chopped in order to > match the same style of meaning as the other lines. A few of course cannot just > so simply be chopped and still make sense though. r103917 reverts a few more, but leaves some of the normalisation
Currently there are only two problem lines left, ...uploadstash table already exists. ...user_former_groups table already exists. ...config table already exists. ...type_action key already set on logging table. Migrating remaining user_options... Beginning batch conversion of user options. No user_options field in the user table. Nothing to migrate...done. ...user table does not contain user_options field. ...have rev_sha1 field in revision table. ...have ar_sha1 field in archive table. that do nothing however stick out without dots.
Oh, and at the very bottom of each run I guess Purging caches...done. is always OK to leave not dot prefixed, but I'm not sure about Checking site_stats row...done.
I have cleaned the output for user_options migration with r105531. Jidanni, can you please review the output? Thanks!
Looks good... ...ug_group field does not exist in user table, skipping modify field patch. ...have us_chunk_inx field in uploadstash table. Purging caches...done. Checking site_stats row...done. Wait, those two lines added at the end. "Checking" surely deserves dots. Maybe each new item added needs a second programmer to make sure it gets dotted.
Those two last checks are not really database updates per see. I guess those can stay as they are.
(In reply to comment #13) > Those two last checks are not really database updates per see. I guess those > can stay as they are. The last one is, and should be fixed. The next to last one is not (and to be honest, they should be probably swapped)
Irritating, isn't it?
Not really.
Last one swapped with r108716.
