[CDBI] Was it deleted?

How do I know that $foo->delete actually deletes the object in the
database?

    my $foo = Foo->retrieve($id);

    # some other session deletes the row from the database

    $foo->delete;



Shouldn't this check the row count?


sub delete {
        my $self = shift;
        return $self->_search_delete(@_) if not ref $self;
        $self->remove_from_object_index;
        $self->call_trigger('before_delete');

        eval { $self->sql_DeleteMe->execute($self->id) };
        if ($@) {
                return $self->_db_error(
                        msg    => "Can't delete $self: $@",
                        err    => $@,
                        method => 'delete'
                );
        }
        $self->call_trigger('after_delete');
        undef %$self;
        bless $self, 'Class::DBI::Object::Has::Been::Deleted';
        return 1;
}

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.

On Thu, 2006-09-21 at 13:21 -0700, Bill Moseley wrote:
> 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.

If you actually want to prevent other people from deleting it, you
probably want a SELECT...FOR UPDATE or similar to get a write lock on
it.

> 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.

Yes, if you use delete triggers that's probably the most likely reason
to care about this.  Otherwise, most people won't mind if an object they
wanted to delete was deleted by someone else.

- Perrin