EvdB has asked for the wisdom of the Perl Monks concerning the following question:

I've been using Class::DBI to create a web site and it is going nicely. I now want to create a comprehensive test suite that tests the site via the web using Test::WWW::Mechanize. The problem is getting CDBI to grab new data from the database after a change has been made on the site.

The problem rests with CDBI's cache of objects in memory. This code demonstrates the problem: 

  # In test suite.

  # Check CDBI object is as expected.
  is $cdbi_object->name, 'Foo', "name is correct (Foo)"

  # Change the name through web site.
  $mech->get_ok('http://localhost:3000/object/change?name=Bar');

  # Check that the name has changed.
  is $cdbi_object->name, 'Bar', "name has changed to 'Bar'";

  # Test fails.

[download]

Arguably the tests should fail as there is no way for one instance of perl (test) to know that the object has changed in another (webserver). The tests can be made to work as they should by inserting something like this before the test that checks for changed values: 

  # Reload the object from the database.
  $cdbi_object->remove_from_object_index;
  $cdbi_object = My::Object->retrieve( $cdbi_object->id );

[download]

To get to the point is there a simpler and better way to do this. Can the cache be turned off completely? Is there a way to get a method like $cdbi_object->freshen that will do the above? Am I missing the point

--Me, me, me: http://prlmnks.org/rss, http://scrpbk.com/~evdb, http://ecclestoad.co.uk.

Replies are listed 'Best First'.
Re: Reloading CDBI objects from database elegantly
by perrin (Chancellor) on May 19, 2005 at 20:05 UTC
    This is not a cache, nor is it related to the "live objects index" that people sometimes confuse with a cache. The issue is that you have an object, populated with data, and it stays that way unless you do something to it. All database/object mapping tools work this way.

    All you need to do is get rid of the object and load it again. If you let it go out of scope or undef it and then call the constructor (retrieve) again, you will get fresh data.

[reply]

      Quite right, as the following code shows: 

      use strict;
use warnings;

package Foo;
use base 'Class::DBI';
__PACKAGE__->connection( 'dbi:SQLite:dbname=db_file', '', '' );
__PACKAGE__->table('foo_table');
__PACKAGE__->columns( All => qw/id name/ );
# create table foo_table ( id integer primary key, name char(10) );
1;

package main;

use Test::More 'no_plan';

# In test suite.
my $cdbi_object = Foo->create( { name => 'Foo' } );

# Check CDBI object is as expected.
is $cdbi_object->name, 'Foo', "name is correct (Foo)";

# Change the name through web site.
ok( Foo->db_Main->do("update foo_table set name = 'Bar'"),
    "update name to 'Bar'" );

# undef and reload object.
ok my $cdbi_id = $cdbi_object->id, "get id";
$cdbi_object = undef;
ok $cdbi_object = Foo->retrieve($cdbi_id), "retrieve object";

# Check that the name has changed.
is $cdbi_object->name, 'Bar', "name has changed to 'Bar'";

ok( $_->delete, "delete object" ) for Foo->retrieve_all;

      [download]

      Still it would b e nice if this could be done more easily with something like $object->freshen.

      --Me, me, me: http://prlmnks.org/rss, http://scrpbk.com/~evdb, http://ecclestoad.co.uk.
[reply]
[d/l]
[select]
      Are you saying that some ORMs let you,
      1. Create an object.
      2. Store it.
      3. Retrieve it into some variable a.
      4. Retrieve it again into some variable b.
      5. A change to a won't change b?

      ----
      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

[reply]
        All of the perl ones work that way, except for the latest version of Class::DBI which does some tricks with an index of loaded objects and weakrefs to avoid this. And that has caused so many user complaints that I'm hoping to turn it off in the next release.

        ORM or not, once you retrieve data from the database and hold it in a variable, it has no way of knowing that the underlying database has been changed. This usually doesn't matter since the data is kept in variables for only a short time. Where it does matter, people have to use locking schemes to deal with it.

[reply]

Back to Seekers of Perl Wisdom