Re: Inheritance question.

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

Thanks for the reply. An explanation, if you're interested:

Though they both point at the same table, I want the objects of one class, Music::CD, to be instantiated with all possible columns/values/methods; and I want objects of the other, Music::CD::Cacheable, to be instantiated only with a subset of those. Why?

Music::CD I use when "live" data is absolutely neccessary.

Music::CD::Cacheable I use when it's not, and when DB connections are at a premium. (This is a big, busy system.) Music::DB::Cacheable inherits a modified retrieve() (via CDBI::CACHEABLE) that first looks for a serialized version of the object on disk before attempting retrieval (and then disconnection) from the DB.

I want to avoid grabbing certain columns/values when instantiating a Music::CD::Cacheable object because A) I know I won't need them in the cache; and B) I don't want to grab any columns/values that, if accessed, would lead to CDBI opening an unwanted DB connection (e.g. where ad hoc inflation would occur, as with basic has_a stuff). 

Why not just serialize a hash of the keys/values I'm interested in? Having a uniform interface to the data is very nice, especially considering the size of this particular project. It's also nice to be able to use various special purpose (non-straight-accessor) methods, whether or not you're using "live" or cached data. Further, thanks to CDBI's inflate-on-call handling of has_a/has_many stuff (where the items to be inflated are themselves CDBI objects, anyway), it makes easy the sensible separation of related cache entries.

For example:

package Music::CD::Cacheable;

__PACKAGE__->has_a(artist => 'Music::Artist::Cacheable');

Both Music::CD::Cacheable and Music::Artist::Cacheable inherit that caching version of retrieve(). So you instantiate a Music::CD::Cacheable object. "artist" points to a flat ID. You serialize and store the object that way. When you later retrieve it and call artist(), "artist," which itself wants to inflate to a Cacheable object, is first sought in the cache, and then retrieved/serialized/written if it's not there. The cached "CD" and "artist" objects are separate files at this point, which means they can be reused separately, and purged separately.

I've got it all working, and it's been very handy, but there were just those couple of issues I had to find workarounds for. (Which is why I was wondering if has_a() really called retrieve() -- the example above actually doesn't work as written.)

TRL


>From: Tony Bowden <tony-cdbitalk@xxxxx.xxx>
>To: cdbi-talk@xxxxxx.xxxxx.xxx
>Subject: Re: Inheritance question.
>Date: Tue, 15 Jun 2004 07:38:38 +0100
>
>On Tue, Jun 15, 2004 at 06:55:36AM +0100, trlorenz@xxxxxxx.xxx wrote:
> > The idea is that Music::CD and Music::CD::Cacheable both want to
> > inherit the methods of Music::CD::BASE.
>
>OK, so far.
>
> > Being more robust than Music::CD::Cacheable, Music::CD wants to add
> > to the inherited methods a few accessors of its own;
>
>This is where you lose me. If they're both pointing at the same table,
>why does this one have extra accessors?
>
> > to do this, it's got to call columns(). The problem is, there's no
> > public interface (that I know of) to *add* columns to the Essential group;
> > you can only replace the entire group.
>
>Why not add them to a completely different group that doesn't already
>exist?
>
> > Apparently, one could directly manipulate the "Essential" group via
> > __grouper() in each class, but the double underscores are intimidating.
> > My solution currently is to delete "artist" from the symbol table after
> > the columns() call in Music::CD, but that's obviously pretty gross.
>
>So calling a method with two underscores is worse than direct symbol
>table hacking? :)
>
> > Would it be a bad idea to have a class method add_columns() in addition
> > to columns() to support this type of inheritance? Or is there a completely
> > different way to set this sort of thing up? Or is this type of inheritance
> > a Bad Thing for reasons I don't grasp?
>
>I'm still not sure why you need it, but the next version of Class::DBI
>will probably have a little less intimidating access to the Grouper. I'd
>rather not just keep adding delegation methods to it if we can just make
>it public itself for people who really need it. The private accessor to
>it will keep working for a while (probably with a deprecated warning) so
>you can safely use it for now without risking its sudden disappearance)
>
>Tony