Hi Peter, > -----Ursprüngliche Nachricht----- > Von: "Peter Rabbitson" <[email protected]> > Gesendet: 03.02.09 10:11:57 > An: DBIx::Class user and developer list <[email protected]> > Betreff: Re: [Dbix-class] Last stable version of DBIx::Class and DB2 V9.1
> > When writing tests it helps to simulate the _exact_ circumstances which fail > otherwise. Anything else is an exercise in futility. Please try this: You're right. I was just wondering... ;-) But I got a reaction... :-)) > [...]CODE[..] I tried the code and it returned: -----------------------------------------8<------------------------------------------------- 1..6 ok 1 - Exception with RaiseError => 1 ok 2 - PrintError => 1 works not ok 3 - No exception on do() with RaiseError => 0 attribute passed # Failed test 'No exception on do() with RaiseError => 0 attribute passed' # at am1.pl line 32. # died: DBD::DB2::db do failed: [IBM][CLI Driver][DB2/LINUXX8664] SQL0204N "XXXX.IS_REALLY_NOT_HERE" is an undefined name. SQLSTATE=42704 not ok 4 - No warning with PrintError => 0 attribute passed # Failed test 'No warning with PrintError => 0 attribute passed' # at am1.pl line 34. # got: '1' # expected: '0' ok 5 - No exception on do() with RaiseError => 0 set ok 6 - No warning with PrintError => 0 set # Looks like you failed 2 tests of 6. > > 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. That's really a hard job...therefor I know what you're doing. :-) > 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. That's a reason why I offered to help as I know that it is burdensome to get a test environment up and running. > I didn't lie to you when I said > many of use use the dev releases in production. Don't understand me wrong. I just wanted to give you the sight of an first visitor. You know yourself that the first impression counts. ;-) I took the time to join the mailing list and writing down my two errors I got wile testing. I'm sure that there are many people out there which would cancel a proof of concept right after the failing tests and never giving feedback. You really don't need to explain yourself. I honour and respect all work done. > > It is arguable whose loss it will be if you decide not to go with DBIC :) > I will see... :-)) > Anyway I hope that the test I sent above will clear things up. Be sure, it does. As you spent some time for me I spent some time investigating the sources of DBI and DBD:DB2. There seems to be a really bad inheritance problem between DBI and DBD::DB2 as far as I can see. The do-subroutine of DBD::DB2 calls SUPER::do when there are more parameters (in case of attributes). DBI::do does a dbh->prepare with much more parameters as the external API (docu) says. When DBI::do does call prepare is calls DBD::DB2::prepare which ignores the additional parameters. I don't know who is responsible for that. Fact is: DBD::DB2 does not fulfill the API. And you're right! IMHO DBI does something which is not a good style for OO-programming. I will try to contact the DBD::DB2 guys. Thank you. Best regards Andreas _______________________________________________ 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]
