[Dbix-class] Re: Tests for MySQL's illustrious 0000-00-00

[Matt S Trout]

On Mon, Jul 28, 2008 at 09:59:17AM +1000, Robert Loomans wrote:
> >This is the right thing to do in terms of database agnosticism
> >also: if you treat 0000-00-00 like NULL, the API will exhibit
> >consistent semantics regardless of whether you’re using MySQL
> >or a real database. In contrast, the applicability of a swallow-
> >errors-for-this-column option depends on whether you’re running
> >on MySQL or not. It’s a visible unbreak-me switch that needs to
> >flipped when moving between database engines.
> 
> This is exactly my concern. Part of the advantage of using DBI and DBIC 
> is that you shouldn't have to care too much how the DB implements 
> various things.... exposing the DB differences unnecessarily is bad.
> 
> It's less of a problem if the code is developed on MySQL and then 
> deployed on another DB.... the developer will add the column flag during 
> development and be done.
> 
> If the code is developed on another database, and then deployed on 
> MySQL, it *is* a problem as the developer won't necessarily add the 
> magic flag... and the deployed code will seemingly randomly crash.

If the code is developed on another database, and then deployed on MySQL,
MySQL should be configured in a modern fashion such that 0000-00-00
isn't valid and doesn't get into the database in the first place.

THis option is -only- for *MySQL-specific* code that has no choice but to
work with a legacy broken MySQL setup.

There are no portability issues whatsoever, because a portable app simply
wouldn't use the broken mysql "feature".

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/