Re: object cache/index multiple apps -- best practice?

[prev] [thread] [next] [Date index for 2004/07/19]

Perrin Harkins said:
 > That's not good.  It means you have scoping problems somewhere, 
either in your
 > own code or in Perl's behavior (see the recent thread about scoping 
of return values).
 > Disabling the object index should not alter the behavior of a program 
without scoping
 > problems unless that program was counting on being able to to work 
with two separate
 > objects representing the same row of data at once.  The only other 
situation where
 > people have had problems is when they have an incorrect primary key 
set, or objects
 > that contain data in TEMP columns which can not be identified by a 
primary key.

I'm not sure if I'm following. Take the following example:

  # from within process_a
  my $obj = MyClass->retrieve(1);
  # invoke process B to do something to that table
  system('process_b'); # process_b changes the table in question
  $obj = MyClass->retrieve(1);
  # $obj does not reflect update

Is the scoping issue here that the second retrieve is executed *before* 
$obj is destroyed by the assignment, therefore reflecting the values in 
the cache?

As for disabling the object cache with $Class::DBI::Weaken_Is_Available 
...that seems like it could definitely be fleshed out. I'd like to see 
the ability to disable cacheing on a per-table basis so that you can 
enjoy the benefits on tables where it doesn't matter, but disable it on 
tables where it's absolutely essential that every read consults the 
database.

Thanks,
Matt