Re: the case of construct() and the missing database row

[prev] [thread] [next] [Date index for 2004/07/15]

On Thu, Jul 15, 2004 at 12:19:42PM +0100, Tony Bowden wrote:
> On Thu, Jul 15, 2004 at 04:08:53AM -0700, Patrick Michael Kane wrote:
> > The bad thing, for me at least, is that I don't find out that this has
> > happened until I actually start calling methods on the object in
> > question and the error that is returned.  I'd like to just skip the
> > missing object and move on to the next one, without blowing up.
> 
> There's no sensible way Class::DBI can handle this (assuming you're in a
> transactionless environment) It's a classic race condition: at any point
> between Class::DBI telling you the object represents a real live
> database row, and you trying to do anything with it, someone else,
> possibly on a different machine using an application written in Python,
> could have removed the row you're referencing.

This reminds me...

 sub update {

	...

        my $rows = eval { $sth->execute($self->_update_vals, $self->id); };
        return $self->_croak("Can't update $self: $@", err => $@) if $@;

 >>>    # enable this once new fixed DBD::SQLite is released:
 >>>    if (0 and $rows != 1) {    # should always only update one row
                $self->_croak("Can't update $self: row not found") if $rows == 0;
                $self->_croak("Can't update $self: updated more than one row");
        }

any good reason that's still not enabled?

Tim.