We have found a major bug in MySQL that causes MySQL to silently truncate date in LONGTEXT fields when innodb is used and MySQL fails to convert characters in a string to the configured charset of the column. This results in mangled/destroyed data. Since MySQL is kind enough to not report any issue and simply trash your data I consider it quite major. We have verified in a few versions of MySQL of 5.0, 5.1 is harder because innodb is not included on some of our test platforms.
Normally if there are characters that MySQL can't interpret in a field mysqlclient will display the characters with a ? place holder, but what we have found is simply terrible error handling. We have found this issue by trying to store email messages that were converted to 8BITMIME in a LONGTEXT field. Some characters will fall outside of UTF8, latin1 or others. Once MYSQL sees a character it can't interpret it just trashes you data and truncates it rather than failing and throwing an error. It is easy to workaround by using LONGBLOB rather than LONGTEXT or never store 8BITMIME encoded email in a longtext field. It is related to this, http://bugs.mysql.com/bug.php?id=18908, but not exact. We are developing a test to easily verify this bug for others to reproduce without a lot of setup. It has hosed us bad so I thought I would enlighten anyone who tries to store email in a database. Beware because if you try to store email in MySQL, which btw is a really bad idea, your email server may convert email to 8BITMIME automatically if you define a content filter. Some like Postfix always convert to 7BITMIME when a filter is enabled, thus, no issues arise. But other MTA's do conversion to 8BITMIME automatically and need a configuration setting to disable. Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
