Matt S Trout wrote:
All appears to be working fine, but I notice from the debugging SQL that
the date field (dob) is always updated, even though the submitted value
is identical to the stored value of the retrieved record, ie:
UPDATE users SET dob = ?, gender = ? WHERE ( id = ? )
I assume this is because I am using InflateColumn::DateTime on the date
fields. If I dump $user->last_name I get a scalar, but $user->dob gives
me a complex data structure (the DateTime object?). But I'm not sure why
it is trying to update the date field. Presumably it's harmless, as the
update would silently fail anyway?
My suspicion would be that your DB isn't sending back the same datetime
string as is being saved, so the update always -thinks- the data's changed
even though the column values are equivalent.
If so, the DateTime::Format::NameOfYourDb module probably needs patching.
Fancy trying warn $obj->get_column('dob') before+after to see if I'm right?
Result of 2 updates where only a non-date field should have been affected:
PRE: 1934-12-21
POST:1934-12-21
PRE: 1927-09-09
POST:1927-9-9
However, looking again at the docs it's quite possible that I'm not
using the InflateColumn::DateTime function properly as I don't actually
call inflate or deflate before updating or after searching (rather using
my own function to transform dates to/from MySQL format, and/or using
dob.strftime() function in the templates). Could that have anything to
do with the inappropriate field update? Meanwhile I'll have a play with
InflateColumn::DateTime.
--
Richard Jones
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
