[moved to dbi-dev]
On Sat, Mar 20, 2004 at 07:16:13PM +0200, Marko Asplund wrote:
> Tim Bunce wrote:
> >On Mon, Feb 09, 2004 at 02:26:22PM +0200, Marko Asplund wrote:
> >>On Fri, 2004-02-06 at 15:00, Tim Bunce wrote:
> >>>On Fri, Feb 06, 2004 at 11:33:54AM +0200, Marko Asplund wrote:
> >>>>On Wed, 2004-02-04 at 21:08, Tim Bunce wrote:
> >>>>
> >>>>>Try running the DBD::Oracle v1.12 t/long.t using DBD::Oracle v1.15
> >>>>>(I don't know if it'll work or not, I don't think anyone's tried that)
> >>>>
> >>>>t/long.t from DBD::Oracle v1.12 runs without errors with v1.15 driver.
> >>>>tests number 195-198 fail in v1.15 t/long.t.
> >>>
> >>>So the tests have improved to catch this case. You could also try the
> >>>other way. Run the v1.15 t/long.t with DBD::Oracle v1.12 (you'll have to
> >>>disable/ignore some test for new features like the ora_lob_* functions).
> >>
> >>i disabled the LOB test block starting on line 278 in DBD::Oracle v1.15
> >>t/long.t. using DBD::Oracle v1.12 driver tests number 13, 106 and
> >>195-198 fail. with v1.15 driver tests 195-198 fail.
> >>
> >>>But whatever happens, I'm sure the problem is with Oracle.
> >>
> >>yes, i understand this but if possible it would be nice to not make the
> >>user worry whether a test failure is an indication of a real problem or
> >>not for example by skipping the test, outputting an informative message,
> >>by listing expected test failures by product version or some other way.
> >
> >I agree. Patches welcome.
>
> i finally got around implementing this feature. now t/long.t tests
> number 195-198 are skipped on Oracle8i. this is implemented by writing
> client library version to a file in Makefile.PL and then loaded in
> t/long.t. i'm using Data::Dumper dumped hash because there might be more
> compile/runtime environment attributes that need to be passed e.g.
> server version. i'm not using mk.pm to not interfere with the
> configuration mechnism.
Thanks. In my current copy I'd already done this:
ok(0, $tmp = $sth->fetchall_arrayref, 1);
if ($DBI::err && $DBI::errstr =~ /ORA-01801:/) {
# ORA-01801: date format is too long for internal buffer
warn " If you're using Oracle <= 8.1.7 then this error is probably\n";
warn " due to an Oracle bug and not a DBD::Oracle problem.\n";
sleep 1;
ok(0,1) for (1..5);
}
else {
ok(0, @$tmp == 4);
ok(0, $tmp->[0][1] eq substr($long_data0,0,$out_len),
cdif($tmp->[0][1], substr($long_data0,0,$out_len), "Len
".length($tmp->[0][1])) );
ok(0, $tmp->[1][1] eq substr($long_data1,0,$out_len),
cdif($tmp->[1][1], substr($long_data1,0,$out_len), "Len
".length($tmp->[1][1])) );
ok(0, $tmp->[2][1] eq substr($long_data2,0,$out_len),
cdif($tmp->[2][1], substr($long_data2,0,$out_len), "Len
".length($tmp->[2][1])) );
#use Data::Dumper; print Dumper($tmp->[3]);
ok(0, !defined $tmp->[3][1], 1); # NULL # known bug in DBD::Oracle <= 1.13
}
So it checks for just the specific problem. You still get a failure,
but just one, and a message explaining the cause so the user can
decide if it's significant for them.
I think that's sufficient.
Thank you very much for contributing and you're welcome to do more.
(I'd recommend that you use subversion to keep current with the latest
changes and also email me with details of any proposed implementations
so I can point you in the right direction.)
Tim.
