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 16:44, Todd Lorenz wrote:
> Now, then... I wouldn't have thought these requirements would be that 
> unusual, really. There must be cases where people need to cache their data 
> in a semi-permanent state, not only for speed, but to reduce connections.

I can only speak for myself, but this is the first time I've ever heard
someone ask for it.

> Anyway, I was using BerkeleyDB originally, but just serializing the objects 
> themselves wound up being much easier.

I would have just serialized them all into BerkeleyDB.  In fact, rather
than mess with changing the behavior of Class::DBI to work without a
database I would just make my own objects that mimic the Class::DBI API,
copy the data into them, and store them in BerkeleyDB.  Class::DBI
objects are fairly easy to extract data from and the part of the API you
want to allow is very small.

You could use a class factory approach for this, telling it to give you
either Class::DBI objects or BerkeleyDB objects depending on a config
setting.

> >You just need to customize the serialization on your objects so that
> >they don't store that data.  Check the Storable docs.
> 
> Talking about CDBI in the regular, non-serializing sense, here: I'd think 
> you'd rather store the flat ids as foreign-key attributes rather than the 
> inflated objects, anyway. You've got the object cache, now, so why not use 
> it? It might be a cleaner implementation always to dip into the cache for 
> id-based lookups; always to retrieve(), in fact.

First, it's not a cache.  It is an index of live objects.  Making things
faster and reducing load on the database were not goals of that change. 
You can't expect that the related object will be found in the live
objects index.  It would only be found there if something else in the
current scope is already using it.

What has_a does really *is* a cache.  You could argue that it shouldn't
cache, and that each new call to $album->artist() should result in
another database hit.  There is no guarantee that the has_a relationship
is to another Class::DBI object though.  I often use Time::Piece objects
with a custom inflate() method.  I think that might be the reason for
the caching.

Which reminds me, maybe you can get the view of the object you want by
calling the same methods that Class::DBI does when it wants to deflate
an object for storage.

- Perrin