+1 for 86'ing warnings in favor of errors. A warning is treated as low-priority by many. It may never be fixed bug in the eyes of many devs.
A warning is a possible point of argument between dba and coder. Conceivably a preponderance of warnings could become an error or issue at the organizational level. I'd rather my devs execute their sql, see things as an error and make schema and coding changes prior to the code and table (etc) struct getting into production. If their sql doesn't execute because it's an error. They HAVE to fix it to roll their code. -s On Fri, Dec 19, 2008 at 12:58 PM, Jay Pipes <[email protected]> wrote: > 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 > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
