Mark wrote: > A release candidate for amavisd-new-2.4.2 is available at:
> http://www.ijs.si/software/amavisd/amavisd-new-2.4.2-rc2.tar.gz > Changes since -rc1: > - further README.sql updates regarding data type TIMESTAMP in MySQL; > - when recipient notifications for bad headers is enabled, and a message > is spam with bad headers, recipient would receive an empty notification > message (because message contents category is spam and recipient > notification template for spam is empty); now a general recipient > notification is sent in this case, and additional check added to ensure > that empty notifications would not be send even if explicitly configured > to be empty; > - ignore $timestamp_fmt_mysql if SQL database driver (DBD) is not 'mysql'; > - MySQL workaround: changed default clause in $sql_clause{'upd_msg'} to: > UPDATE msgs SET time_iso=time_iso, ... > just in case one forgets to use "DEFAULT 0" on "time_iso TIMESTAMP"; > Mark Mark, will this also set $timestamp_fmt_mysql = 1; if SQL database driver (DBD) *is* 'mysql' ? If not, then as I have said off list, I believe there is a potential for loss of data under a particular circumstance we have discussed. If $timestamp_fmt_mysql is false, data to the msgs.time_iso field will be written in a form such as '20060615T041046Z'. MySQL will not know what to do with this, so it will write '0000-00-00 00:00:00' to the msgs.time_iso field. With this, a command like the previously recommended: DELETE FROM msgs WHERE time_iso < now() - interval 7 day; will delete all newly added records after the upgrade. With $timestamp_fmt_mysql false, the previous behavior was MySQL would write the current time in the field any time the table was updated. The data was first written as all zeroes during the INSERT, then later an 'UPDATE msgs' command by chance wrote the current time into the field. This was a 'misfeature' of the way the field was created. If you create a field as TIMESTAMP NOT NULL (in other words, if no DEFAULT is given, it is actually created as TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP I agree that it is not correct to rely on a misfeature for a program to work, and I also prefer an obvious failure instead of subtly wrong result, but if nothing else, people should be aware that there is a potential for loss of data. The ideal scenario would be if there was a way automatically determine what format the data should be in before it is INSERTed. Gary V _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
