Re: [CDBI] Subclass load order problem with relationships

lianna-EIBgga6/0yRmR6Xm/[email protected] 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:

http://lists.digitalcraftsmen.net/pipermail/classdbi/2006-September/thread.html

In particular:

http://lists.digitalcraftsmen.net/pipermail/classdbi/2006-September/001333.html

With the one caveat:

http://lists.digitalcraftsmen.net/pipermail/classdbi/2006-September/001335.html

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.

-Oli

_______________________________________________
ClassDBI mailing list
ClassDBI-Ra3b/[email protected]
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFLmfSSbWXajvTQ+URAu6bAJ91xLDLTBjXqlqUElUcm4cfWkvoowCgstyf
XG1YW2JyvPfMZEO1Las2obU=
=NOGK
-----END PGP SIGNATURE-----