> > My initial purpose for suggesting such a test suite was the > initial difficulty I had when I first wrote a DBD: docs were pretty > thin, and there was a lot of painful trial and error. And I'm > certain I'm *still* not in conformance in a lot of places > (esp. as DBI API changes roll out). If each DBI release > contained updated conformance tests, DBD authors could simply > rerun the latest conformance test against their latest driver > and (hopefully) find out empirically where any non-conf's occur.
Yep... I'd like that too. > > Also, did you mean > > ..."conformance" and "functional"... > > rather than > > ..."conformance and "performance"... Read that as Performing correctly, but since it rhymed, I left it :) It would be interesting, though, to have benchmarks comparing a loop of 1000 inserts vs execute_array() timing :) > > The latter has implications that aren't neccesarily relevant > to conformance/correctness (Tho I still believe in > 'Damn the metadata, FULLSPEED AHEAD!') But, the metadata is important. Take a look at DBD::ODBC's test suite (specifically the .pm file). It's rudimentary, but it creates tables on multiple platforms and inserts and verifies the inserts, which can be painful. > > Conformance can be pretty simplistic, tho I'd like to see > thorough coverage (hopefully better coverage than some other > conformance suites I've used, e.g., JDBC). Since DBI itself > wraps much of the processing of underlying DBDs in its own > processing, perhaps 2 conformance suites are needed: > > 1. DBI layer conformance: to test that the end-to-end > functionality is correct. This would likely be written > entirely in std. DBI/perl doing the usual DBI API calls. > > 2. DBD conformance: this may require more work, but actually > be a smaller set of tests. > Essentially, it creates a "pseudo" DBI layer that just > exersizes the DBD i/f calls that the DBI layer (as opposed to > a DBI app) makes. > > The latter may be more useful for driver writers, while the > former is more useful to end-users. Also, some > instrumentation for performance might be useful, esp. as > driver writers roll out new releases: rerun the conformance > test(s), and see where things slowed down or sped up. Yes... I think we are on the same page. Although, as I thought about it more, the correctness being verified by DBI is important to me as a driver writer too... Jeff
