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

Peter Rabbitson rabbit+dbic at rabbit.us
Wed Mar 27 14:20:33 GMT 2013


On Wed, Mar 27, 2013 at 01:54:00PM +0000, David Cantrell wrote:
> On Wed, Mar 27, 2013 at 11:49:53PM +1100, Peter Rabbitson wrote:
> > On Wed, Mar 27, 2013 at 12:30:03PM +0000, David Cantrell wrote:
> > > Eeuuww!
> > > I would thunk that in_storage should be "rolled back" too.
> > How would you implement that? (as in how would the perl logic actually 
> > look)
> 
> in the code that flips that bit ...
> 
> if we're in a transaction
>   store in the transaction (handwave handwave, i've not looked at the code)
>     a tuple of [ref to object we're updating, the old value of in_storage]
>   update it
> fi

What happens on:

my $result = $rs->new({...});

<stuff happens>

$schema->txn_do({
  < more stuff happens >
  < an insert happens incorporating $result, maybe directly maybe as part of a multicreate >
  $result->in_storage is now true
  <exception happens !!!>
});

Where would we have hooked the event that $result (which note is 
entirely external to the txn_do) got something done to it?

We could potentially have *every* $result object register a weakref to 
itself in its schema when its in_storage changes from 0 to 1, and have 
stuff being flipped back in case the objects are still alive but... gut 
feeling says I am missing something...

In any case - if it is all that there is to it - you are simply looking at
::Row::insert(), and at $self->result_source->schema->storage->txn_depth()
to figure out if you are in a txn or not...

Please handwave a bit more ;)



More information about the DBIx-Class mailing list