[Dbix-class] DBIx::Class::Relationship::CascadeActions::delete(): Not in database

[Peter Rabbitson]

On Mon, Mar 25, 2013 at 10:51:50PM -0700, Bill Moseley wrote:
> Here's a rather contrived example:
> 
> 
> my $artist = $schema->resultset( 'Artist' )->first;
> 
> eval {
>     my $guard = $schema->txn_scope_guard;
>     $artist->delete;
>     die 'rollback!';
>     1;
> };
> 
> #$artist->in_storage(1);
> $artist->delete;
> 
> 
> Produces:  DBIx::Class::Relationship::CascadeActions::delete(): Not in
> database
> 
> I'm trying to remember if there's a way to handle code like this.    I came
> across it writing tests (where I made some changes, and then rolled back to
> revert the changes).  I don't really see that there could be a general way
> to handle it, but thought I'd ask.
> 
> Is forcing in_storage ok in this case?

>From https://metacpan.org/module/DBIx::Class::Row#delete

:: If you delete an object within a txn_do() (see "txn_do" in 
:: DBIx::Class::Storage) and the transaction subsequently fails, the 
:: result object will remain marked as not being in storage. If you know 
:: for a fact that the object is still in storage (i.e. by inspecting 
:: the cause of the transaction's failure), you can use 
:: $obj->in_storage(1) to restore consistency between the object and the 
:: database. This would allow a subsequent $obj->delete to work as 
:: expected.