FYI, if folks decide we can scrap warnings, I can mentor a community
member in the task of replacing warnings with errors. It's not a
particularly difficult task, basically broken into 4 phases:
1) Identify all code locations that emit warnings
2) Replace with errors
3) Remove the warnings system entirely
4) Fix EXPLAIN EXTENDED to not use SHOW WARNINGS afterwards (this was
always a total hack)
-jay
Jay Pipes wrote:
Brian and I discussed this earlier today and I'd like to get the
community's input on this.
Basically, MySQL lets you, via various SQL_MODE settings, throw warnings
instead of errors in a variety of places. For instance, on inserting
data that is too big, MySQL *may* throw a warning depending on the
sql_mode or whether the statement is a multi-insert statement...
I find this behaviour to be odd, and so does Brian. I mean, what
*really* is a warning? If your data is being truncated, to me, that
should be an error, not a warning.
Because of this warning/error mix, the code in the server is riddled
with things like the following, taken from drizzled/sql_insert.cc:
/*
Count warnings for all inserts.
For single line insert, generate an error if try to set a NOT NULL
field to NULL.
*/
session->count_cuted_fields= ((values_list.elements == 1 &&
!ignore) ?
CHECK_FIELD_ERROR_FOR_NULL :
CHECK_FIELD_WARN);
session->cuted_fields = 0L;
Besides the obvious WTF does "cuted_fields" mean, this kind of stuff is
all over the place, and sometimes the heuristics of when to throw a
warning and when an error is downright confusing.
My idea is to completely scrap all of this type of stuff and simply
throw errors when bad data is encountered.
What are your thoughts? Should Drizzle have a "warning" mode?
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
