On Thu, Sep 26, 2013 at 05:55:56PM +0100, Martin J. Evans wrote:
> On 25/09/13 17:28, Tim Bunce wrote:
> >
> > G2. driver developers adopt DBIT as a free test suite with good
> > coverage of the DBI API. This is the pay-back _for_ developers.
>
> I think one thing many DBD test suites could benefit from is wrappers
> around many of the DBI methods that wrap that method in tests e.g.,
> when execute is called, did it return undef, a true value (0E0 or a
> number > 0) or -1 depending on whether it is a select statement or
> not. If test suites were converted to use those I'm sure we'd find
> quite a few issues in DBDs but still using existing test code.
I don't follow you here Martin. DBIT will implement detailed testing for
the return value of execute.
> > G9. end users can find the level of DBI API compliance of a driver
> > i.e., by looking at the test configuration for the driver
> > to see what areas of functionality are configured to be skipped.
>
> This in particular is something I'd like to see and expand on.
>
> [...]
> a capability system beyond what get_info provides. get_info is pretty
> much ODBC's SQLGetInfo and few drivers beyond DBD::ODBC really support
> it that well.
I'm expecting that one of the side-effects of DBIT will be a great
improvement in support for get_info by drivers. That'll be a win for all.
It's also worth noting that we can define our own meanings for certain
values passed to get_info. With surprising foresight, sometime around
1998 I think, I arranged for the get_info values 9000 thru 9999 to be
reserved for the Perl DBI in the ISO standard registry:
Registry of Values for the SQL Standard (ANSI X3.135 and ISO/IEC 9075)
With especial attention to values related to SQL/CLI ([ANSI/]ISO/IEC 9075-3)
I actually reserved value ranges for just about all of the SQL CLI functions.
http://www.nntp.perl.org/group/perl.dbi.users/2007/04/msg31285.html
> [...]
>
> If I put my mind to it (and looked at my code from years ago when I
> was involved in writing to multiple DBDs from the same application) I
> could proably come up with a much longer list - Peter probably could
> too.
When the time comes we'll probably need one :)
> I know this is not DBIT as such and you might see it as a distraction (if you
> do, ignore) but I think it would be worth while.
Very. I think it's important.
> > R3. work well with cpantesters,
> > so we get good coverage (perhaps extend Test::Database)
>
> As a side note, I as going to add support to Test::Database for
> DBD::ODBC because I thought it might get me more smokers actually
> running the tests. Then I discovered it needed create database
> support, and that was not going to happen with ODBC as each database
> has totally different syntax for that and some databases need very
> high level permissions to create a database.
As I mentioned elsewhere, I suspect we'll want to extend or fork
Test::Database to bend it to our needs.
> These seem like worthwhile goals. Whether I can be of any help, I
> don't know, but I'll at least try and keep up with the discussion and
> provide any useful feedback.
Thanks Martin.
Tim.
