Re: DBI::Test's DESIGN.md
Jens Rehsack <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 02.07.2013 um 00:56 schrieb Martin J. Evans <[email protected]>: > 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 [email protected]