Update to 1.3 fails: "Data truncated for column 'ipaddr' at row 1" with exisitng rows in mail_logger table

I noticed this warning as well. It appears to be specific to changes introduced in 7.x-1.3 and related to the creation of a new "ipaddr" column in the mail_logger DB table (via mail_logger_update_7001()). The column does appear to be created despite the warning, which likely explains why things continue to function.

The new column spec sets "not null" but does not provide a default. I think this is fine for new installations, but for sites being updated, with existing rows in the mail_logger table, I think this may cause some issues. Though the column will get created it's initial value for existing rows will be NULL, which is probably not so good for a NOT NULL column definition. I'm not sure how this would lead specifically to a "data truncated" warning, but it still seems like defining a default value would solve things. Maybe someone with more intimate knowledge of D7 schema definitions would be able to confirm this?

It looks like the schema does not need an official default value on the ipaddr column so long as the update specifies an initial value. My assumption is that an empty string would be an appropriate initial value for this case, so the fix here is really just a one liner in mail_logger_update_7001() such that 'initial' => '' is added to the field spec.

However, we still have a significant problem for any users who have already tried to update to 7.x-1.3. These users' failed attempt at the initial update may have left them with potentially corrupt data and schema info. Even if they use a patched version (with the fix described above) they will still potentially have NULL values in their ipaddr column and incorrect null/default settings on their DB server. This probably means:

1. This issue is at least major in priority
2. We'll need yet another update hook to try and detect/correct these cases (clearing NULL values and refreshing the column definition).

The attached patch takes a stab at this.

Thanks for the patch. I had found that simply rerunning update.php seemed to "fix" it, but this is better.

I just wanted to see if the maintainers are close to tagging a 1.4 release. This issue may be forcing some people to stay at 1.2 (as in our case), or if they did already move to 1.3 they may have some bad data in their DB.

done

Great, thanks!