Re: retrieve() hits db even if obj present in %Live_Objects.

[prev] [thread] [next] [Date index for 2004/06/24]

On Thu, 2004-06-24 at 14:23, Todd Lorenz wrote:
> db connections should be made only when a 
> needed item is not found in the cache -- and should be closed as soon as any 
> db lookup is complete. I'd like also to be able to disable lookups that are 
> *not* id-based (to avoid db connections), and to disable inserts, deletes, 
> and updates to the db.

Those are pretty unusual requirements.  Class::DBI may be the wrong
thing to use for this.  I would look at a simple hash-based thing like
BerkeleyDB or Cache::FastMmap instead.

> _do_search() suffers from (and underlies) the same problem that retrieve() 
> has -- Tim's patch will fix the problem with retrieve(), specifically, as I 
> understand. Still, will _do_search() be able to recognize an id-only lookup, 
> and try the cache before calling sql_Retrieve()? (Not that I care, actually, 
> if retrieve() works and I can disable non-id-based searches)

What kind of action would result in _do_search() being called for an
ID-only lookup other than a retrieve() call?

> Another problem is has_a, which causes foreign-key attributes to be inflated 
> in place upon object instantiation, via _simple_bless. This is undesirable 
> for my purpose, because I'd much rather have 10 frozen albums that all 
> "point" to one artist, rather than 10 frozen albums that also carry 10 
> frozen copies of the same artist.

You just need to customize the serialization on your objects so that
they don't store that data.  Check the Storable docs.

> An unrelated-but-related problem: How to set up a CDBI::Album::BASE class, 
> from which an industrial-strength CDBI::Album (your rank-and-file CDBI 
> class) and a lighter CDBI::Album::Cacheable class (containing some, but not 
> all, of the methods/data available to CDBI::Album) derive. Some of the 
> current CDBI class setup routines make this kind of thing tricky. (So if 
> anyone's read this far, and is remotely interested, I can blather on about 
> that, as well.)

Go ahead, but please start a separate thread for it.

- Perrin