Why SQL_mode will be required for long time.

This is my considerations/thoughts after reading:

http://karlssonondatabases.blogspot.com/2012/02/why-i-think-sqlmode-is-useless.html
http://ronaldbradford.com/blog/why-sql_mode-is-essential-even-when-not-perfect-2012-02-16/

It is not possible to remove SQL_mode and in particularly not to remove ‘non-strict’ modes without breaking a lot of applications. The problems occurs with a table like this

CREATE TABLE `test`.`strict`(
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`col1` VARCHAR(10) NOT NULL,
`col2` VARCHAR(10),
PRIMARY KEY (`id`));

.. and an INSERT statement like this:

INSERT INTO `test`.`strict`(`col2`) VALUES (‘string’);

Such ‘incomplete INSERT’ (where  not all columns are listed) will fail in strict mode for non-NULLABLE columns that do not have a DEFAULT (`col1` in this case – not `id` because AUTO_INCREMENT is equivalent to a DEFAULT in the context) – because:

1) The first thing the server will check is, whether a DEFAULT has been defined.  Since not the case for `col1`, proceed to step 2.
2) Next check is if it is possible to insert NULL. Obviously not possible for `col1` here as the column is declared NOT NULL. Proceed to step 3.
3) Third check is if ” (empty string) can be inserted for string columns and ’0′ (ZERO) for numericals. ‘strict’ mode does not allow it.

Server is left with only one alternative: to return an error. What is does and what is also one of the intentions with ‘strict’ mode. But if the applications needs it it will have to set SESSION sql_mode to a ‘non-strict’ mode. Not all users and admins on application-level has the privilege to change GLOBAL sql_mode (and it could also affect other applications) or make the column NULLable or add DEFAULTs.

Don’t forget that many servers serve a wide variety of applications. The discussion has a tendency to center around high-profiled deployments with a single application on the server.

I also think that is rarely a problem to have ” (empty string) instead of NULL in a table. But having ’0′ (ZERO) instead of NULL can lead to very misleading results in calculations (of an average for instance). The statements “this person ows me nothing” and “I don’t know if he ows me anything” are definitely not the same. So this is something to be careful about when working in ‘non-strict’ mode: all non-specified numbers INSERTed are set to ZERO.

Also quite a lot of applications will still use plain INSERTs for User Mangement (what they should not – they should use GRANT|REVOKE instead). That caused problems for some applications (including Workbench) with MySQL 5.5 were new columns were added to the user table. So also here there are some compability concerns (but I believe that the columns were made NULLable in recent releases).

So in conlusion I don’t think we will (or should) get rid of sql_mode soon (and if somebody thinks that applications affected should be rewritten I cannot disagree, but I am not so naive that I think it will happen soon).

What I request however is a little consistence. The Windows installer/configurizer will set a ‘strict’ global mode as default. Installing on Windows from the ZIP-archive and any installation method on *nix will not. If the Windows installer team had the intention to improve the server, why didn’t they take it to the server team instead? We have seen quite a lot of cases where people have migrated data from a hosted application to a local Windows machine (for testing, for learning or whatever) and then something suddenly doesn’t work as before because they are not aware of the differences in the default setup on different platforms and what effects it has.