Am 02.07.2013 um 00:56 schrieb Martin J. Evans <boh...@ntlworld.com>:
> Apologies for top posting and I'll give this post the attention it deserves > later (by all means track me down Jens if I forget) but one thing struck me > immediately and that was sections in DBD pod like DBD::ODBC's deviations from > the DBI specification at > http://search.cpan.org/~mjevans/DBD-ODBC-1.43/ODBC.pm#Deviations_from_the_DBI_specification > > Some of these might be really difficult to deal with in test code. Over the > years I've submitted many patches to tighten the DBI specification but at the > end of the day having maintained a DBD for quite a while deviations from the > specification are just reality. Trying to make all DBDs the same is a really > difficult task which DBI does well for the most part but I keep coming up > with new cases - just search in dbi-dev for threads containing > "clarification" from me. In particular see last_insert_id which DBD::ODBC has > almost no chance of supporting. > > As an aside the err, native and errstr are still a continual problem for some > of the work I do in that there is only one per DBI and they are not per stmt > - contrary to ODBC where the native error and error string is per stmt, dbc > or env. Yes, I could have done something about this but it always seemed > harder to address than it first seemed since it is engrained in DBI since day > one. Or my memory could be worse than I think and Tim will correct me. That's all right, and even more worth finding a good solution for overall specification testing. But that (even if quick read Tim's reply before going to be convinced me) takes exactly the same line as Tim's suggestion for AUTHOR_TESTING … I will make a proposal in the reply of Tim, hope that doesn't hurt you :) Cheers -- Jens Rehsack rehs...@gmail.com
