2010/9/8 Martin J. Evans <martin.ev...@easysoft.com>:
> On 08/09/10 08:58, Jens Rehsack wrote:
>> 2010/9/7 Martin J. Evans <martin.ev...@easysoft.com>:
>>> After a small discussion on #perl today I found a small amount of time to
>>> look at 51dbm_file.t test failures. There are a few things I noted:
>>>
>>> 1. ribasushi suggests the tests fail because it does a rmtree when still
>>> connected so the files are still open and this fails on Windows. I don't see
>>> this problem but I imagine it would be solved by disconnecting, rmtree then
>>> reconnecting.
>>
>> The error was a failure in DBD::File::Table::file2table function for
>> quoted table
>> names which have a path component (which needs to be supported for
>> backward compatibility).
>>
>>> 2. I'm a bit suspicious about the:
>>>
>>> $test_dir .= "_" . basename($0, qr/\.[^.]*/);
>>>
>>> in lib.t because basename docs say:
>>> "@suffixes work as in fileparse() except all regex metacharacters are
>>> quoted" so those '*' and []^ will be taken literally. It does work if you
>>> just change that to ".t".
>>
>> Well, currently t/lib.pl supports even test scripts with any other extension,
>> e.g. "sandbox/rtxxxxx.pl".
>> I don't see any reason to change this.
>
> The reason to change it is it does not work:
>
> perl -le 'use File::Basename; print basename("/home/martin/51dbm_file.t",
> qr/\.[^.]*/);'
>
> 51dbm_file.t
>
> The docs for basename say:
>
> "@suffixes work as in fileparse() except all regex metacharacters are quoted"
>
> so those metachrs in the suffix list are treated literally.
But I give there a regex o.O
I think I need to check the source to understand.
> The obvious intention of whoever wrote this was to take the extension out but
> it does not work. I don't know why the extension was taken out other than
> maybe '.' is not allowed in some directory names in some operating systems
> (VMS).
I added the basename because of a misinterpretion of an error in
parallel tests test.
It could be completely removed - $$ should do. At first, I had the
feeling, some tests
are executed in the same process, which was simply a bug in clean up
(which is now
fixed).
>>> 3. personally I don't like ok calls without a test name as it makes it hard
>>> to find the tests when looking at the code and comparing it with the test
>>> output.
>>
>> You're absolutely right here - a good test case name would be
>> "select from full qualified path name as table"
>
> I'll add test names this morning.
>
>
>>> 4. the test that fails for me is test 7 which does a:
>>>
>>> select * from
>>> C:\Users\martin\DBI-1.613_93\test_output_5084_51dbm_file_mine\fred
>>>
>>> which returns no rows. I'm not sure why as that is the name of the file.
>>
>> I do not understand why you aren't sure about what. I would be happy to
>> explain.
>>
>>> I'd be happy to fix (2) and (3) and I don't think (1) will hurt but as I
>>> cannot reproduce a problem with the rmtree as reported by some. Instead the
>>> error I see is the last select which returns nothing.
>>
>> That#s correct, for some reason something during DBD::DBM::Table::open_file()
>> fails because of the bug in DBD::File::Table::file2table. I couldn't
>> figure out what
>> failed and why there was no error message, I assume it's the PathTools error
>> with non-existing path's when concatenating file names.
>
> As I said in a follow up, all tests pass for me now on the trunk of DBI.
Anyway, if there is something you didn't understand in the tests, I
should explain.
It's always good when more than one guy understands what's going on.
/Jens
