On Thu, Sep 21, 2006 at 03:41:31PM -0400, Edward J. Sabol wrote:
> Bill Moseley asked:
> > Shouldn't this check the row count?
>
> You mean the number of rows affected by the SQL delete statement, right?
> Anyway, no, I don't think it should really, but that's just my opinion. You
> might want to look into using transactions if you're worried about another
> process deleting records that you're using....
Yes, that's what I meant. I'm using transactions but to catch that
you have to use serializable transactions and re-read the objects once
inside the transaction. Then all that fails when using "nested"
transaction since you can't change the isolation level once a select
has been done inside a transaction.
Of course, even if CDBI did check the row count there's the issue of
what to do with the triggers if no rows are updated.
Still, might be handy to do this (well, as an eample):
DB->do_transaction( sub {
DB::History->add("$user deleted $thing");
$thing->ledger->credit( $thing->cost );
$thing->delete || die "Failed to delete";
});
I've overridden delete so I can do this.
Highlight