[Dbix-class] Reconnecting Behavior

Adam Herzog adam at herzogdesigns.com
Mon Jul 30 22:55:03 GMT 2007


On Jul 30, 2007, at 5:28 PM, Brandon Black wrote:
> On 7/30/07, Adam Herzog <adam at herzogdesigns.com> wrote:
>> Okay; I think I have this fixed.
>>
>> I ended up having to create a new, dummy db and chmoding it in order
>> to prevent SQLite from connecting. The fix ended up being fairly
>> straightforward once I had a sane test. No exception was being thrown
>> if the connection failed, because it was checking $dbh (which was
>> always true) instead of $DBI::errstr, which had the actual failure
>> message.
>>
>> Can somebody put their eyes on this and let me know if I've
>> overlooked anything (and commit if I haven't.)
>
> Ugh, that's cute.  Here's what the DBI docs say:
>
> 'If the connect fails (see below), it returns "undef" and sets both
> $DBI::err and $DBI::errstr. (It does not explicitly set $!.) You
> should generally test the return status of "connect" and "print
> $DBI::errstr" if it has failed.'
>
> How about we check all three, as in: "if !$dbh || $@ || $DBI::errstr"
> on the appropriate line?

I saw that in the docs, but I guess I was too focused on my own use  
case, where $dbh was becoming a hashref (with RaiseError, PrintError,  
et al), and thus evaluating as true. I didn't think that checking  
$dbh would buy us anything.

But, I guess in a situation where an empty $dbh is coming from a  
coderef (and not setting $@ or $DBI::errstr) AND 'unsafe' is set (so  
it isn't getting turned into a hashref), we'll need to check.

Updated patch is attached.

-A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reconnect_2.diff
Type: application/octet-stream
Size: 2058 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070730/3ba6693b/reconnect_2-0001.obj
-------------- next part --------------




More information about the Dbix-class mailing list