[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