[Dbix-class] Reconnecting Behavior

[Adam Herzog]

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

Thanks!

-A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reconnect.diff
Type: application/octet-stream
Size: 2049 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070730/0e898891/reconnect.obj