Comments on: Apparent vs. actual data integrity http://www.pythian.com/news/1463/apparent-vs-actual-data-integrity/ News and views from Pythian DBAs Fri, 10 Feb 2012 13:01:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Log Buffer #133: A Carnival of the Vanities for DBAs http://www.pythian.com/news/1463/apparent-vs-actual-data-integrity/#comment-334905 Log Buffer #133: A Carnival of the Vanities for DBAs Fri, 30 Jan 2009 17:08:15 +0000 http://www.pythian.com/blogs/1463/apparent-vs-actual-data-integrity#comment-334905 [...] colleague Sheeri wrote a great blog post on MySQL’s default silent truncation behavior and how this can affect your database server’s data [...] [...] colleague Sheeri wrote a great blog post on MySQL’s default silent truncation behavior and how this can affect your database server’s data [...]

]]> By: Kristian Nielsen http://www.pythian.com/news/1463/apparent-vs-actual-data-integrity/#comment-333464 Kristian Nielsen Mon, 26 Jan 2009 08:18:56 +0000 http://www.pythian.com/blogs/1463/apparent-vs-actual-data-integrity#comment-333464 As I understand it, the underlying reason for the silent truncation, and for most of the other ignore-error behaviour, is due to the support for non-transactional storage engines, especially MyISAM which was the first engine and still the default on non-Windows installs I believe. Since MyISAM cannot roll back a partial change, the issue is what to do when a problem is detected half-way through a multi-row update or insert. Truncating the value (or other error-ignoring action) allows the statement to complete, but leaves possibly wrong data in one row. Aborting would leave half an update in the database, which can also cause serious inconsistencies. Either way we loose. With InnoDB there is no such problems, as we can rollback just the offending statement on detecting an error. Personally I would install MySQL with InnoDB and strict-mode defauls. However even an engine like NDB (which is transactional) does not fully support this, as it cannot roll back the last statement (only the whole transaction), which leads to some of the same problems. As I understand it, the underlying reason for the silent truncation, and for most of the other ignore-error behaviour, is due to the support for non-transactional storage engines, especially MyISAM which was the first engine and still the default on non-Windows installs I believe.

Since MyISAM cannot roll back a partial change, the issue is what to do when a problem is detected half-way through a multi-row update or insert. Truncating the value (or other error-ignoring action) allows the statement to complete, but leaves possibly wrong data in one row. Aborting would leave half an update in the database, which can also cause serious inconsistencies. Either way we loose.

With InnoDB there is no such problems, as we can rollback just the offending statement on detecting an error. Personally I would install MySQL with InnoDB and strict-mode defauls.

However even an engine like NDB (which is transactional) does not fully support this, as it cannot roll back the last statement (only the whole transaction), which leads to some of the same problems.

]]> By: Robert Hodges http://www.pythian.com/news/1463/apparent-vs-actual-data-integrity/#comment-333450 Robert Hodges Mon, 26 Jan 2009 06:20:49 +0000 http://www.pythian.com/blogs/1463/apparent-vs-actual-data-integrity#comment-333450 Really have to agree with you on this one. Silent truncation is poisonous for applications because once you start ignoring the errors it's quite painful to go back and fix them properly. It's the same problem as adding constraints to a schema that already has bad data. Really have to agree with you on this one. Silent truncation is poisonous for applications because once you start ignoring the errors it’s quite painful to go back and fix them properly. It’s the same problem as adding constraints to a schema that already has bad data.

]]>