I thought the whole point of DBI is that once you have a DBI handle the perl code by and large does not need to know what the driver is
Ideally, yes, but it's overkill to write a database engine that parses and processes INSERT and SELECT statements if your goal is to produce statement handles that read arrays (something very useful, particularly to database drivers).
As such I don't see why the Sponge module is in the DBD space let alone shipped with DBI.
DBD::Sponge is usually used by other database drivers. As a building block for building database drivers, it is fitting for it to be in DBI.
As such I don't see why the Sponge module is in the DBD space
Where else would you put a DBD?
I was more looking for defences and criticisms of them as solutions.
DBD::Sponge: Unless you're testing a module that expects nothing but executed statement handles, not useful. Sorry, I thought I had made that obvious.
DBD::Sqlite: No criticisms, thus my post. It's supported by popular ORMs, so it's excellent if your app/distro uses such an ORM.
Why would DBI be installed on a test machine but not a sensible driver?
Who cares. The installer handles all that for you.
The question makes no sense anyway. A sensible driver for one purpose is not sensible for another. A particular driver that's sensible today won't be sensible tomorrow.
In reply to Re^3: How to write test scripts depending on DBI
by ikegami
in thread How to write test scripts depending on DBI
by SilasTheMonk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |