[Dbix-class] Pointless update on a date field

[Richard Jones]

Matt S Trout wrote:
>> Result of 2 updates where only a non-date field should have been affected:
>>
>> PRE: 1934-12-21
>> POST:1934-12-21
> 
> That one looks like it shouldn't have updated.
>  
>> PRE: 1927-09-09
>> POST:1927-9-9
> 
> That one looks like what I was expecting.
> 
> You should just be dealing in DateTime objects and using the DBIC accessors;
> the inflate/deflate will be transparent.
> 
> If you're using your own code to transform dates to/from mysql format you're
> doing it wrong and any bugs are your problem. 

Yes I know - my own code was just to get me going so I could retrieve 
stuff from the db when the user inputs dates in any EU format (I use 
Date::Calc::Decode_Date_EU to extract the year/month/day info). I knew I 
would have to revisit InflateColumn at some stage.

I have setup the table class as shown in DBIC::InflateColumn::DateTime, ie:
__PACKAGE__->add_columns( dob => { date_type=> 'date' } ),

but not:
__PACKAGE__->inflate_column( dob => {
   inflate => sub { ... },
   deflate => sub { ... }
} ) as described in DBIx::Class::InflateColumn.

There is obviously something amiss because if I omit my own 
date_to_mysql() method then system tries to retrieve dates in dd/mm/yyyy 
format.

 > You can get the object DBIC
 > does to do it via $storage->datetime_parser.

Not sure how to get from there to having DBIC transparently convert the 
users date input to mysql format so I can do things like:

my $rs = $c->model('Schema::Foo')->search( \%form_data );
$c->model('Schema::Foo')->find($id)->update( \%form_data );

without me having to do anything (manually) with the date fields in 
%form_data (apart from first validating they not invalid eg 31st 
February). Thanks for your help so far.
-- 
Richard Jones