[Dbix-class] Thank you and DBD capabilities

Martin J. Evans martin.evans at easysoft.com
Wed Jan 12 19:27:07 GMT 2011


I'd just like to say a big thank you all the guys developing dbic for 
their feedback on DBD::ODBC and in particular the testing, bug reporting 
and patches I've received; it is greatly appreciated.

In particular, I'd like to thank Caelum, frew and ribasushi (irc nick 
names, you know who you are).

Since being more active on #dbi and #dbi-class I hope I've helped a few 
people but I've also got tremendous help and feedback myself which has 
made being part of this community so worth while.

Over my years of programming I have often be involved in trying to write 
database neutral code and although I have found this easier with DBI in 
Perl and ODBC (mostly via C) it is still a PITA more often than not so I 
salute the dbic developers who have a mammoth task. Recently a few 
issues of DBD capabilities have come up repeatedly on #dbi and 
#dbi-class channels and it struck me that the SQLGetInfo/GetInfo-style 
interface DBI uses (inherited from ODBC) is just not good enough to 
describe some of the capabilities DBDs (and far worse DBDs which support 
multiple drivers like ODBC) are capable of which can cause dbic real 
headaches. An example:

Does this DBD (and driver underneath it in the case of DBD::ODBC) 
support multiple active statements?

I've not looked at dbic code but I guess this is a difficult question to 
answer and in the case of DBD::ODBC it is a nightmare because (some ODBC 
drivers do, some don't, some do after version X, some do with hack y, 
some do if you add a connection attribute etc). I looked at adding some 
capabilities to DBD::ODBC for different drivers but I don't even know 
which driver it is until after connecting and in some cases (e.g., 
adding MARS_Connection attribute), it is too late after connecting.

Now, I'm not volunteering to do anything in particular about this (I 
cannot even fulfil the comittments I already have) but I think at least 
it might be worth the dbic developers feeding back to DBI those 
capabilities they struggle with ascertaining. At the very least, it 
might help with DBI 2. I'd be prepared to at least keep the list. 
However, if anyone else has some good ideas on this and in particular 
energy and tuits it might very well be worthwhile investigating.

Thanks again for all input to DBD::ODBC - keep it coming ;-)


More information about the DBIx-Class mailing list