Issue #6382 has been updated by Stig Sandbeck Mathisen.
We need TRADITIONAL, one of STRICT_ALL_TABLES or STRICT_TRANS_TABLES, and I'd also add ERROR_FOR_DIVISION_BY_ZERO, and one of NO_ZERO_DATE or NO_ZERO_IN_DATE They should be set globally, but may be set in the connecting session. If using MySQL, documentation should recommend the usage of a transactional database, like InnoDB. For an existing database, migrating from MyISAM to InnoDB is relatively quick and painless. Some descriptions taken from the "tell MySQL to behave" chapter at http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html ## TRADITIONAL ## Make MySQL behave like a “traditional” SQL database system. A simple description of this mode is “give an error instead of a warning” when inserting an incorrect value into a column. Note: The INSERT/UPDATE aborts as soon as the error is noticed. This may not be what you want if you are using a nontransactional storage engine, because data changes made prior to the error may not be rolled back, resulting in a “partially done” update. ## STRICT_ALL_TABLES ## Enable strict mode for all storage engines. Invalid data values are rejected. Additional detail follows. ## STRICT_TRANS_TABLES ## Enable strict mode for transactional storage engines, and when possible for nontransactional storage engines. Additional details follow. ## ERROR_FOR_DIVISION_BY_ZERO ## Produce an error in strict mode (otherwise a warning) when a division by zero (or MOD(X,0)) occurs during an INSERT or UPDATE. If this mode is not enabled, MySQL instead returns NULL for divisions by zero. For INSERT IGNORE or UPDATE IGNORE, MySQL generates a warning for divisions by zero, but the result of the operation is NULL. ## NO_ZERO_DATE ## In strict mode, do not permit '0000-00-00' as a valid date. You can still insert zero dates with the IGNORE option. When not in strict mode, the date is accepted but a warning is generated. ## NO_ZERO_IN_DATE ## In strict mode, do not accept dates where the year part is nonzero but the month or day part is 0 (for example, '0000-00-00' is legal but '2010-00-01' and '2010-01-00' are not). If used with the IGNORE option, MySQL inserts a '0000-00-00' date for any such date. When not in strict mode, the date is accepted but a warning is generated. ---------------------------------------- Bug #6382: We permit silent truncation, and probably other data corruption, in MySQL databases https://projects.puppetlabs.com/issues/6382 Author: Daniel Pittman Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: Doh! Target version: Affected Puppet version: Keywords: Branch: At the moment, and as seen in #6380, we permit MySQL to silently truncate long strings rather than raising an error. We should probably send the appropriate set of "don't be stupid" configuration commands to MySQL to have it fail rather than corrupt information, including string truncation, magical zeroing of invalid dates, and so on. This would turn these into explicit failures, generate bug reports, and end up with code that doesn't lose data. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
