[CDBI] Subclass load order problem with relationships

Oliver Jeeves oj at defuturo.co.uk
Thu Oct 12 17:05:32 BST 2006

lianna at planet.nl wrote:
> Hi,
> This problem has been biting me for days until I eventually found the cause
> (class loading order) and a way to reproduce it.
> ...
> In my particular application I'm working on a CMDB where all devices are
> stored
> in one common table since they have a lot of common information. Some of
> these
> devices however also require specific additional information (a router
> is not
> quite like a server), so I'm utilizing subclasses and additional tables,
> and I'm
> bless()'ing into the subclass at loadtime if necessary. This worked well
> until I
> moved my classes into separate files and I had a lot less control over class
> loading order. What I noticed foremost was that my date columns
> (inflated/deflated
> to Time::Piece objects) stopped working for my subclasses. They became
> simple
> scalar columns. It took me a long time to work out that it was caused by my
> subclasses being loaded first.
> Output of the programs below:
> ... 
> Note that the only difference between these two programs is the location
> of the
> declaration of the My::TestCDBI::Child* classes - in testbad.pl they
> come before
> the declaration of My::TestCDBI, in testgood.pl they come after that.
> As far as I've been able to establish so far any kind of relationship
> defined in
> the subclass when it's loaded first mess up the relationships that are
> defined in
> the parent class. If there are no such definitions there is no problem,
> as the
> My::TestCDBI::Child class shows - the datetime column continues to work
> there.
> Does someone have a solution to this? Or maybe it should be filed as a bug?
> Cheers,
> Lianna

There was a thread about subclassing CDBI objects on here a while ago,
and I was having similar problems to you; When reblessing a CDBI object,
the relationships for the new class didn't work.

I never thought it might have something to do with class loading order,
although I suppose it does make sense. It would also explain why that
method worked for some other people, but not for me.

Either way, I found a solution that works without having to worry about
class loading order, I posted them on this list back in September:


In particular:


With the one caveat:


In addition, I've also added create triggers to automatically set the
'type' field based on what class insert was called on.

I hope this helps.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.digitalcraftsmen.net/pipermail/classdbi/attachments/20061012/21f59b29/signature.pgp

More information about the ClassDBI mailing list