[Dbix-class] Bug(?) and question
Matt S Trout
dbix-class at trout.me.uk
Wed Feb 15 15:40:30 CET 2006
On Tue, Feb 14, 2006 at 04:33:31PM -0800, Alan Humphrey wrote:
> I was finally able to get back to my migrating data problem. I tried to do
> this:
>
> $obj->update($cols);
>
> where cols is a hash ref. No luck. The update went through
> Relationship::CascadeActions and the database update was never called.
> This worked:
>
> $obj->set_columns($cols);
>
> $obj->update();
>
> Is this a bug?
update
$obj->update;
Must be run on an object that is already in the database;
issues an SQL UPDATE query to commit any changes to the
object to the db if required.
Consistent with the POD and the implementation. update() on a resultset takes
arguments though. We should probably modify $obj->update to match.
> New problem/question. It turns out that the default datetime format used by
> MySQL is incompatible with SQLServer. Simply using the MySQL value (all
> zeros) in the update statement to SQL Server gets an error. For this
> particular app I can trap the update and simply null out the value.
>
>
>
> But a broader question comes up. How do you do column level validation
> using DBIx::Class?
Have a look at the DBIx::Class::Validation component for a first cut
by Aran Deltac that could be developed into something suitable.
--
Matt S Trout Offering custom development, consultancy and support
Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
More information about the Dbix-class
mailing list