[Catalyst] ->model-> return values?

[Roderick A. Anderson]

Matt S Trout wrote:
> Roderick A. Anderson wrote:
> 
>>Matt S Trout wrote:
>>
>>>Roderick A. Anderson wrote:
>>>
>>>
>>>>I'm 'looked-out'  Been searching and reading for the last two hours with 
>>>>no good results.
>>>>
>>>>A pointer/suggestion/clue-stick would be appreciated.
>>>>
>>>>Do I need to wrap a
>>>>
>>>>	$c->model( 'TheModel' )->update( ... )
>>>>or
>>>>	$c->model( 'TheModel' )->delete( ... )
>>>>
>>>>in an eval block to check for success or failure or ( hope, hope, hope ) 
>>>>can I just test the return value?
>>>
>>>Assuming you're using DBIx::Class, it depens what you mean by success or 
>>>failure - do you mean success as in "updated/deleted something" or as in "ran 
>>>the appropriate query successfully" ?
>>
>>Sorry it seemed so clear in my mind.  :-)
>>
>>Yes using DBIx::Class.
>>
>>If the update or delete succeeded in updating or deleting; not just running.
>>
>>So if an update query should fail because NULL got passed to a NOT NULL 
>>field, a letter got into an INT field, etc. or an delete fails because 
>>the key doesn't exist.  I'm looking to determine if the update or delete 
>>succeeds then do one thing if it fails then another.
> 
> 
> If the DB throws an error on the statement you'll get an exception.
> 
> If not I -think- you'll get number of rows affected, but not 100% sure without 
> looking. If you don't, prod the dbic list because I suspect that would count 
> as a bug.
> 
> Note that if you find eval unpleasant, you're gonna run into other problems - 
> most of Catalyst+DBIC stuff does exception-on-fail, in fact I'd say a majority 
> of OO perl stuff does. There are modules that provide try/catch semantics if 
> you prefer that way (Error.pm springs to mind), personally I just learned to 
> love eval and $@ :)

Love's pretty strong but live with works for me.  I've used eval a bunch 
in straight DBI/DBD stuff but wanted to make sure I wasn't doing some 
extra redundancy stuff if the magic of the ->model was doing it already. 
  Should have said that in the first place.

Thanks,
Rod
-- 



>