> Note that the test suite will not be trying to test the database,just the driver. And only those parts of the driver behaviour mandated by the DBI spec. Drivers will still need their own tests for any driver-specific behaviour.
The test suite could provide sets of "nonstandard" tests that the driver author would invoke simply by saying "and run these tests for qqiweuuqweiw feature as well". Me being lazy, I admit I do not test everything that would be needed to make DBD::XBase fully tested. If I could specify what features my driver (= the database) supports and have tests run for me, that'd be great.
Of course, the ->func calls and driver_ attributes will still need to be done by hand. But maybe while doing it by hand driver authors will even find ways of providing the functionality using native DBI ways.
One of the features of the Rosetta API is that the Engine (driver) you choose to implement the API can/needs-to declare which parts of the API it supports, and which parts it doesn't (not mentioning a feature in the support manifest is the same as saying it isn't supported, giving us forwards compatability).
Essentially, this is a standard way of knowing when to "skip" tests or not; if an Engine/driver explicitely says that it implements a feature, then the corresponding tests will run and the Engine/driver will fail its tests if it fails to do what it says it can.
Extrapolating this out, features that are only available in one database/driver are visible through the API as an API feature that only one Engine/driver claims to implement. (Note that, while rare, the Rosetta API even includes a few features that no database, that I know of, currently supports, though perhaps ought to. A measure of forward-thinking if you will. But not unreasonable.)
Note that, aside from knowing which tests to run, one of the main reasons that Rosetta has the feature manifest is so that applications built on top of the API can declare explicitely what database features they require, and it will be easy for them to programatically detect which Engines/drivers the application can use. That useable set contains the Engines/drivers which claim the required features and pass the tests for them.
Note that, technically, having a driver claim "I support this" is referring to the combination of the driver and the database engine. It is quite normal, if perhaps slower, that some features will be implemented or emulated in the driver itself, and not the database. It is up to the Engine/driver writer to decide. But then, thats what DBD modules already do with DBI; for example, they emulate "?" place-holders when the database itself doesn't do it.
-- Darren Duncan
P.S. If you're wondering why I use the word "Engine" instead of "driver", it is because the way I look at this, if the system were a car, then the driver is the application, since it says what to do and when, the Rosetta API is the dashboard, steering wheel, etc, and the Engine is what makes things happen when the controls are pressed. In my model, the Engine is the sum total of the database itself and the Perl glue between it and the API. I note that this analogy works for both client-server and embedded databases, where in some cases the DBD module *is* the database. Still, this is just technicalities or terminology.
