On Tue 15 Oct 2002, Kate L Pugh wrote:
>> -- is that evil? Relying on DBI to give me the right error message?
On Wed 16 Oct 2002, Peter Haworth <[EMAIL PROTECTED]> wrote:
> Yes; error messages will always change in the future.
That's what I thought, but I couldn't figure out another way of doing it :(
> You could test $dbh->err or $dbh->state for more robust checking.
perldoc DBD::Pg (1.13, the latest version) says that it doesn't
support the state method yet, and that the err method "returns
PQresultStatus of the current handle". I looked up PQresultStatus on
www.postgresql.org and found the following:
PQresultStatus can return one of the following values:
* PGRES_EMPTY_QUERY -- The string sent to the backend was empty.
* PGRES_COMMAND_OK -- Successful completion of a command returning
no data
* PGRES_TUPLES_OK -- The query successfully executed
* PGRES_COPY_OUT -- Copy Out (from server) data transfer started
* PGRES_COPY_IN -- Copy In (to server) data transfer started
* PGRES_BAD_RESPONSE -- The server's response was not understood
* PGRES_NONFATAL_ERROR
* PGRES_FATAL_ERROR
Which doesn't look too promising in terms of differentiating between
errors caused by a concurrent update failure and other kinds of
errors, and in fact when I tested to see what $dbh->err gave me on a
transaction failure and on a simple typo in the SQL, I got "7" both times.
So that ain't gonna work, unless I'm missing something.
>> An alternative would be to always return 0, but that'd mean
>> flagging an actual error as a conflict, and I'd like to keep those
>> separate since a conflict isn't really an error.)
>
> It's still an error if you don't retry the transaction.
I don't think so, at least not in the context of this problem. What I
meant by "conflict" in the above was "checksum not matching up". See
the additional code at
http://london.pm.org/pipermail/london.pm/Week-of-Mon-20021014/014345.html
I want to return 0 (not die) if *either* the checksum doesn't match,
*or* the checksum does match, but we can't complete the transaction
(which would signal that another instance has got in there and done a
commit in between us checking the checksum and us writing to the
database). The latter case isn't an error, because I have code that
can handle that nicely (tells the user what has happened and asks them
to merge their changes in manually).
Kake
--
http://www.earth.li/~kake/cookery/ - vegan recipes, now with new search feature
http://grault.net/grubstreet/ - the open-source guide to London
http://www.penseroso.com/ - websites for the fine art and antique trade
