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
| 
