Add strict mode - Treating warnings as errors

[xaprb]

Go doesn't offer a way to see if the statement produced warnings (as far as I know). I thought about some way to access it but it doesn't seem possible through standard database/sql.

Could we have a setting that treats warnings as errors? This would be something I'd enable in development to help avoid writing code that may cause problems. The driver would need to check for warnings after every statement. This data is transmitted in the protocol; it doesn't require a SHOW WARNINGS statement. If there are warnings, a SHOW WARNINGS LIMIT 1 would get the first one, and the driver could return something like "statement caused $N warnings: $first_warning".

Thoughts?

[julienschmidt]

I think there should definitely be a way added to the database/sql package to catch warnings. I plan to propose a few patches in the next weeks.

Adding a few debug options to the driver is definitely possible but right now I give priority to implementing the missing features (TLS/SSL, Compression, LONG_DATA and time.Time parsing) for the first release candidate.

[xaprb]

If you want my opinion, I would say TLS is a very low priority. Not many
people are going to use it in my experience as a consultant. Compression is
slightly more useful but still optional. The last two you mentioned are
more important, I think.

I think it's one of the strengths of this library (as opposed to the others
available) that it is "Go-ish" in its support for the most important and
most common things, in a simple way. Some other libraries are so filled
with features and so confusing that they are scary and hard to use. If I
want absolute compliance and full implementation of every bit of the MySQL
protocol, I will use a wrapper around the official libmysql C library for
sure. So I would encourage you to make this library focused on being
lightweight, simple, some balance of the most useful features, but not
every possible feature. Especially those features that might require
awkward workarounds because of database/sql. If you only implement what
fits well into database/sql, plus maybe a few optional behaviors that are
configurable via flags in the DSN, it will feel "just right" to me.

[julienschmidt]

TLS and compression don't seem to be complex to implement:

• TLS: http://dev.mysql.com/doc/internals/en/ssl.html
• Compression: http://dev.mysql.com/doc/internals/en/compression.html

If they bloat the package to much I`d skip this features for sure.
And you described my initial approach quite well 😉

[xaprb]

Yeah, I know they aren't too complex, but TLS in particular is used by maybe 1 user in 1000. At least, that is what I observed while a consultant at Percona. I think I only remember one or two people actually using it. The problem is it is quite costly for the MySQL server and adds a large performance penalty. It is also very flaky to configure. It is much more robust and flexible to use stunnel or something like that for the specific connections where the encryption is actually needed. So, that's my $.02

Thanks for this awesome library :-)

[julienschmidt]

Can't this be achieved by using the "traditional" SQL mode ?

[serbaut]

Yes, that is probably a better solution. The show warnings approach feels a
bit clunky.

On Wed, Mar 27, 2013 at 8:25 AM, Julien Schmidt notifications@github.comwrote:

Can't this be achieved by using the "traditional" SQL modehttp://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-15508510
.

[serbaut]

However, traditional mode still only generates warnings for things like:

select unix_timestamp('0');
select 1 + 'foo';

[xaprb]

Yes, there are a lot of cases where MySQL will only give a warning. You
also might want MySQL's stricter settings not to be enabled on the whole
server, but only for specific connections, so enabling the variable in the
Go connection would help.