On Sat, Aug 23, 2003 at 10:54:32AM +0200, Hans van Harten wrote:
> Fred van Engen wrote:
> > On Fri, Aug 22, 2003 at 01:16:48AM -0500, Hans van Harten wrote:
> >> that comes with neither warnings nor errors reported ...
> > Error reports would have been nice, but why does your application
> > supply these incorrect dates anyway? Probably because some user typed
> > them. And what are you going to tell the user when you get a generic
> > MySQL error for an INSERT with many values?
> > 'Oops, something went wrong'?
> Planned to dump it into MySQL and check only if MySQL croaked about it.
> 
> > Just check the values in your application, like you should do for any
> > value coming from an external source. Then you can tell the user
> > exactly what went wrong for each field. It also prevents garbage or
> > badly  formatted data from entering your database.
> 
> My checks might not match those of (the next version of) MySQL and at that
> time the difference in thoughts will pass unnoticed !
> 

I agree that MySQL should complain but I'm not sure it should fail. The
problem is that MySQL has always behaved this way and is in many cases
documented to do so. Some programs may expect MySQL to do clipping of
large values (your example in another post) and will fail if this
changes.

Valid dates are clearly defined independently of MySQL. Just don't feed
MySQL anything else. If the presentation changes (YYYY-MM-DD, DD-MM-YYYY
or MM-DD-YYYY) that would need to be documented anyway.

Valid ranges for any field are defined in your table definitions and the
absolute limits are defined in the MySQL documentation.

If MySQL should fail on a simple INSERT with out-of-bounds values, it
should also fail when the out-of-bounds value is generated in a complex
query involving expressions with fields (or subqueries). How would you
know for which records an UPDATE or INSERT failed? Would you want it to
fail the entire query and not just problematic records or even fields?
That would hardly be possible with MyISAM tables and would need some
kind of subtransactions in any transactioned tables.

Partly failing is silly IMHO and failing completely is difficult. So I
guess it should just warn you that you did something silly. If you use
transactions, you can decide to abort or let MySQL decide that.


Regards,

Fred.

-- 
Fred van Engen                              XB Networks B.V.
email: [EMAIL PROTECTED]                Televisieweg 2
tel: +31 36 5462400                         1322 AC  Almere
fax: +31 36 5462424                         The Netherlands

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to