[Dbix-class] Reconnecting Behavior

Brandon Black blblack at gmail.com
Mon Jul 30 22:28:03 GMT 2007


On 7/30/07, Adam Herzog <adam at herzogdesigns.com> wrote:
> On Jul 30, 2007, at 2:17 PM, Matt S Trout wrote:
> > On Mon, Jul 30, 2007 at 11:03:44AM -0400, Adam Herzog wrote:
> >> On Jul 26, 2007, at 2:17 PM, Adam Herzog wrote:
> >>> On Jul 26, 2007, at 12:19 PM, Brandon Black wrote:
> >>>> As I understand the code, it *should* be attempting reconnection.
> >>>> Any
> >>>> chance you can make a test file that reproduces the behavior?
> >>>
> >>> I've added a test to 33storage_reconnect.t; attached is the output
> >>> of an svn diff against trunk.
> >>>
> >>> Essentially, there was already a test to make sure that it would
> >>> reconnect if it lost its connection. I had to make that
> >>> reconnection fail, so I rename the sqlite file, try to fetch some
> >>> data, rename the file back, and then try to fetch some data again.
> >>> The last fetch fails, when it should succeed.
> >>
> >> After trying to look into the problem, I discovered that my test is
> >> never going to work. After moving the db file and trying to
> >> reconnect, SQLite just creates a new file, so it IS connected to a db
> >> and so it doesn't try to reconnect again.
> >
> > How about if you write "THIS DATABASE IS FULL OF FAIL\n" to the
> > original
> > location of the file and -then- try to reconnect?
>
> 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?

-- Brandon



More information about the Dbix-class mailing list