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

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

> 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.  

Matt, I had similar issues to yours, in a polling daemon that is running 
in a parallel environment. One thing that you can do is to remove each object from
the cache as you retrieve from the DB. 

my @table;
loop {
	@table = Class::DBI::Table->retrieve_all();
	foreach (@Table) { $_->remove_object_from_index();}

	....
}

This is tedious though, and prone to errrors. I agree that table level control is key.

Max



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.
> 
> So, feel free to not use it, but be aware that it may mean something 
> deeper is wrong.
> 
> >I'm just wondering if there's a magic bullet, best practice solution for 
> >this. Can it be disabled  entirely if desired?
> 
> Yes, all you have to do is this:
> 
> $Class::DBI::Weaken_Is_Available = 0;
> 
> - Perrin