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

[Andreas Mock]

Hi Peter,

> -----Ursprüngliche Nachricht-----
> Von: "Peter Rabbitson" <rabbit+dbic at rabbit.us>
> Gesendet: 03.02.09 10:11:57
> 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


> 
> 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