Hi,
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 ;-)
Martin
