Andreas Mock wrote:
> Hi Peter,
>
>> -----Ursprüngliche Nachricht-----
>> Von: "Peter Rabbitson" <[email protected]>
>> Gesendet: 02.02.09 21:41:21
>> An: DBIx::Class user and developer list <[email protected]>
>> 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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
