Comments on: Handling MySQL’s warnings in Go code

By: James Day

James Day — Tue, 25 Dec 2012 14:26:11 +0000

Simon, I know. The problem with STRICT_TRANS_TABLES is that it will cause data loss for applications that need the old setting. You can expect it’ll be the server default in 5.7. I’ll probably file the request for that early in 2013, so it’ll be that way through most of the 5.7 alpha and beta cycle.

My guess is that the timestamp will also be default in 5.7. No direct knowledge of that though.

What we did for the default choices is consider the potential harm that might be done and where we thought they might bite people a bit too hard – say data loss – we went with a more cautious approach in general. Several of the settings ended up changing as a result of different people’s opinions and experiences.

Now would be a good time to think of things that you think should be changed in 5.7 for less backwards compatibility, then file a bug report at bugs.mysql.com with a please tell James about it note. Or you can use other channels, but I prefer bugs.mysql.com for this so others can more easily see the reason.

I agree with you about the desirability of control for individual errors. That’d be another good one for a bug with feature request.

Maybe you might like to file those then blog to invite others to comment on the requests and see what people come up with?

James

By: Simon J Mudd

Simon J Mudd — Mon, 24 Dec 2012 12:06:09 +0000

James, when you do a major version upgrade backwards compatibility does not _have_ to be the default configuration though you probably would need to warn about this. I see 5.6 has a new timestamp option and on startup mysql warns about this but hope that in 5.7 perhaps it becomes the default.

Going back to the original issue posed by Xaprb once you have setup MySQL with the more lenient settings changing this to something stricter is pretty hard and can require a lot of work to see what might break and to fix it. Since “truncation of data” is probably rather infrequent it’s not perceived to happen much and so unless you really can push for this sort of change to happen the work may get delayed … indefinitely.

Certainly a “treat warnings as errors” setting would be good, but the problem is that ideally you’d like to be able to choose which warnings to apply this to as making the blanket change is too intrusive.

By: James Day

James Day — Sun, 23 Dec 2012 20:13:26 +0000

I should perhaps add a little: we’d really prefer it if just about every development platform on the planet defaulted to using STRICT_TRANS_TABLES or a more strict setting by default for new code.

We have to be backwards compatible but that doesn’t mean we want to see new code relying on the non-strict behaviour.

James

By: James Day

James Day — Sun, 23 Dec 2012 20:10:51 +0000

*You might also know that this uses errors by default in MySQL 5.6, which defaults to sql_mode=NO_ENGINE_SUBSTITUTION_STRICT_TRANS_TABLES even on linux for new installations. It already did in 5.5 on Windows if the installer is used and for some of our connectors.

create table a (a varchar(4)) engine=innodb;
insert into a(a) values (“hello”);
ERROR 1406 (22001): Data too long for column ‘a’ at row 1

For backwards compatibility it’s set by the new default my.cnf file, as described at https://blogs.oracle.com/supportingmysql/ .

If you don’t have a backwards compatibility concern and aren’t using our default my.cnf file please set this yourself. While some applications do need warnings instead of errors, we’d prefer it if all possible installations were using sql_mode=NO_ENGINE_SUBSTITUTION_STRICT_TRANS_TABLES or more strict settings.

If the driver author is receptive to suggestions, please consider suggesting that they default to those settings in their connection options, so everyone gets them unless they specifically choose to override them. Most Go code will be new so there’s little reason for a driver to not set the more strict settings.

View are my own, for an official Oracle view please consult a PR person.

James Day, MySQL Senior Principal Support Engineer, Oracle.