[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