[Dbix-class] Last stable version of DBIx::Class and DB2 V9.1

[Peter Rabbitson]

Andreas Mock wrote:
> Hi Peter,
> 
>> -----Ursprüngliche Nachricht-----
>> Von: "Peter Rabbitson" <rabbit+dbic at rabbit.us>
>> Gesendet: 02.02.09 21:41:21
>> An: DBIx::Class user and developer list <dbix-class at lists.scsys.co.uk>
>> Betreff: Re: [Dbix-class] Last stable version of DBIx::Class and DB2 V9.1
> 
>> Sorry for the late reply.
> 
> No problem. I'm thankful to get an answer.
> 
>> The ability to pass connection attributes in db handle
>> calls seems to be DBD dependent, and does not seem to be implemented by DB2.
> 
> I'm pretty sure I have to disagree with you. I just made a little program to test
> what you said. But my test program gives me the feeling that dynamically changing
> the connect attributes via db handle works pretty well. See below for source.

When writing tests it helps to simulate the _exact_ circumstances which fail
otherwise. Anything else is an exercise in futility. Please try this:

use strict;
use warnings;

use DBI;
use Test::Exception;
use Test::More;

plan tests => 6;

my @w;
$SIG{__WARN__} = sub { push @w, @_ };

my $dbh = DBI->connect(
    @ENV{qw/DBICTEST_DB2_DSN DBICTEST_DB2_USER DBICTEST_DB2_PASS/},
    { RaiseError => 1, PrintError => 1 },
);


# make sure things work
@w = ();
dies_ok (
    sub { $dbh->do(q|drop table is_really_not_here|) },
    'Exception with RaiseError => 1'
);
is ( @w, 1, 'PrintError => 1 works' );


# try do() with passed attributes
@w = ();
lives_ok (
    sub { $dbh->do(q|drop table is_really_not_here|, { RaiseError => 0, PrintError => 0 } ) },
    'No exception on do() with RaiseError => 0 attribute passed'
);
is ( @w, 0, 'No warning with PrintError => 0 attribute passed' );


# try do() with preset attributes
$dbh->{RaiseError} = 0;
$dbh->{PrintError} = 0;
@w = ();
lives_ok (
    sub { $dbh->do(q|drop table is_really_not_here|) },
    'No exception on do() with RaiseError => 0 set'
);
is ( @w, 0, 'No warning with PrintError => 0 set' );


>> any case the test is now fixed[1], and will get into the next official maintenance
>> release (which *fingercross* should happen in a week or so). The second part of
>> your question is fixed too[2]. In any case 08010 is still fine to use, all failing
>> tests are due to defficiences in the tests themselves, not problems with the dbic
>> library.
> 
> That is really something you have to think about. When I download, compile AND test
> such a big library/module and I'm willing to learn the functionality I want to feel
> confident at least by working tests. Tests which work wrong are much worse than
> no tests at all.

Exactly - this is why I fixed the test to not be dependednt on the whim of the current
DBD. I also would urge you to think about the fact that we depend on a number of
libraries which are moving targets. Incompatibilities did, do, and will arise. The
additional fact that we do not have easy access to a DB2 database, contributed to the
failing test. Actually I do have access to one, but compiling the DB2 DBD on my machine
seems to be more complex than it should be, I haven't gotten to it yet.

Additionally I have to point out that the stable release has not had any work done on it
for about a year. It was an unfortunate mistake to concentrate development efforts on the
upcoming major point release, but this is what we have. I didn't lie to you when I said
many of use use the dev releases in production.

> You can see by my very first posts to the mailing list that I really don't feel confident
> at the moment. It's a big decision to replace a core functionality like database access
> by a big package as DBIC is. So the errors in the tests caused an "Ooohhhh" with me. :-))
> 

It is arguable whose loss it will be if you decide not to go with DBIC :)

Anyway I hope that the test I sent above will clear things up.
Cheers