Hi Victor,

I agree with the patch you've committed - looks good!

I was curious as to whether you felt it was necessary to take this patch and also make it work on tables which contain more than one DATETIME column that needs upgrading? Or are these tables generally not the ones which grow to 4-5k rows?

Paul seems to indicate to me that the bug_history table won't be affected by this patch (because it contains multiple DATETIME columns). If this is true, wouldn't this table also cause upgrade problems due to it's inevitably large number of rows?

Thanks

I think it is necessary to do two things:

1. Provide a better experience by chuncking the work, rather than having the user experience a server error and retry. A typical user who doesn't know what is happening under the hood won't trust the migration result by having errors + retries. And a lot of users will probably give up before doing the N required retries. If the proper fix for this is risky, then we should only apply it to trunk and not 1.2.x.

2. Handle the case where we have multiple columns.

As for the history table, it only contains one date time. The fields it contains are: id, user_id, bug_id, field_name, old_value, new_value, type, date_modified.

The tables that have two timestamps are: bug, bug note, news, tag, user. I think the most likely ones to possibly hit the limits are bug note, bug and user. However, in the case of the database I was upgrading, none of these hit the limit to cause a failure.

Another thing to note is that we got this error because of the one query per row thing which we don't have often. If there is no work around to avoid the server error in such case and we feel we are going to have more of this kind of query per row updates, then the investment in this area would be justified, otherwise, we should be fine with workarounds like the one I've implemented. Maybe a bit better by just doing 3k rows and then asking user to refresh or something.