cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:

Trying to work out why this isn't returning all the rows of data from the mock. Have I messed up the session instantiation?

use v5.36; use DBI; use DBD::Mock; use Data::Dumper; my $session = DBD::Mock::Session->new('testing' => ( { statement => 'SELECT * FROM bar', results => [ ['one', 'two'], ['three', 'four'] ], } )); my $dbh = DBI->connect('dbi:Mock:', '', '') or die $DBI::errstr; $dbh->{mock_session} = $session; my $data = $dbh->selectall_arrayref("SELECT * FROM bar"); say Dumper({ DATA => $data });

Output:

$VAR1 = { 'DATA' => [ [ 'three', 'four' ] ] };

Replies are listed 'Best First'.
Re: Anyone familiar with DBD:Mock?
by cLive ;-) (Prior) on Feb 07, 2025 at 18:19 UTC
    selectall_arrayref works as expected if I register the mock via $dbh->{mock_add_resultset}
Re: Anyone familiar with DBD:Mock?
by InfiniteSilence (Curate) on Feb 09, 2025 at 05:41 UTC

    From the POD: "There is no distinct area where using this module makes sense..." and I tend to agree. I would make my real data for tests in CSV and use DBD::CSV in my test scripts instead.

    Celebrate Intellectual Diversity

      DBD::SQlite might also work fine. There are lots of tools to edit a SQLite database by hand. I use sqlitebrowser for that.

      Of course, it rather depends on what OP is trying to achieve. Very basic SQL statements should works the same (more or less) in every database. Mocking a specific SQL dialect is a lot harder, and so is error handling. And trancactions.

      Unless there are specific reasons to simulate a database, my recommendation would be to use the real thing for development. Many databases have support for bulk insertion of data, so it would not be too complicated to load a bunch of test data. See my use of COPY for PostgreSQL: Re: [OT] The Long List is Long resurrected

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
      Also check out my sisters artwork and my weekly webcomics