On 26/09/13 23:29, Tim Bunce wrote:> 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.
All I meant was for DBIT to provide method wrappers which incorporate the tests
so when DBD writers write their DBD-specific tests they get the method tests
for free.
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 definitely is a win. I can't even begin to tell you the pain I had writing
DBD neutral code just for ODBC, Oracle, DB2, mysql and postgres. We persevered
for some time but ended up with so much of the class methods overridden we
ended up with effectively 5 different applications - although it did not look
like it from the front. Once you include the SQL as well - it really is not fun
and although I don't use DBIx::Class myself, it must be quite a piece of code.
It will be so much nicer to do:
if ($h->get_info(parameters_need_colons)) {
do this
} else {
do this
}
than
if ($h->{driver} eq 'Oracle' || $h->{driver} eq 'postres') blah blah
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
Nice one.
[...]
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.
Excellent. I will be happy to help with this as I can.
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.
Martin
