in reply to Re^2: How to write test scripts depending on DBI
in thread How to write test scripts depending on DBI

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.

  • Comment on Re^3: How to write test scripts depending on DBI

Replies are listed 'Best First'.
Re^4: How to write test scripts depending on DBI
by SilasTheMonk (Chaplain) on Oct 05, 2009 at 20:36 UTC

    Thanks for the clarifications. That's much clearer.

    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.
    Well yes those are all fair points. Except that:

    1.) When you install DBI you are only guaranteed to get the drivers that come with DBI. None of those are much use for real work. So what puzzles is why so many machines would have DBI but not "real" (highly subjective term) drivers. The arguments are likely to be different for those that happen to CPAN testers machines (my sample) but I am still surprised at the lack of "real" drivers.

      why so many machines would have DBI but not "real" (highly subjective term) drivers

      None at all? No DBD::mysql, DBD::Pg, DBD::Oracle, DBD::Sqlite, DBD::ODBC, or DBD::Sybase? That is odd.

        That is odd.
        Precisely. I'll take that as vindication. ;-)