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

Aargh! The first two answers I understand and know how to do. I was more looking for defences and criticisms of them as solutions.

If I understand DBD::Sponge correctly you cannot use a Sponge handle without knowing it is a Sponge. 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 (leaving aside issues of SQL dialect which obviously DBI can do nothing about.) As such I don't see why the Sponge module is in the DBD space let alone shipped with DBI. The same almost applies to DBD::Mock except that I can see some rather specialized applications for that. For example it might be useful to test a module that constructs SQL statements.

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

Replies are listed 'Best First'.
Re^3: How to write test scripts depending on DBI
by ikegami (Patriarch) on Oct 05, 2009 at 20:24 UTC

    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.

[reply]

      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.

[reply]

        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.

[reply]

In Section Seekers of Perl Wisdom