has_many() problems

[prev] [thread] [next] [Date index for 2005/05/19]

A problem using Maypole 2.09 with Class::DBI 0.96.

I am loading my model classes automatically via Class::DBI::Loader (0.20=
):

MyApp::Entity
MyApp::Product
...

I also have separate files set up for each model class inside which I am=
 setting up relationships manually:

MyApp/Entity.pm:

package MyApp::Entity;
=5F=5FPACKAGE=5F=5F->has=5Fmany(products =3D> 'MyApp::Product');
1;

MyApp/Product.pm:

package MyApp::Product;
=5F=5FPACKAGE=5F=5F->has=5Fa(supplier =3D> 'MyApp::Entity');
1;

If I try to do something in a model class like this:

my $entity =3D MyApp::Entity->retrieve(1);
my $products =3D $entity->products();

Then I get this error:

caught model error: entity is not a column of MyApp::Product at C:/Perl/=
site/lib/Class/DBI/Relationship/HasMany.pm line 121\n

This looks very much like something that is mentioned in the Class::DBI =
docs:

"When setting up the relationship we examine the foreign class's has=5Fa=
() declarations to discover which of its columns reference our class. (N=
ote that because this happens at compile time, if the foreign class is d=
efined in the same file, the class with the has=5Fa() must be defined ea=
rlier than the class with the has=5Fmany(). If the classes are in differ=
ent files, Class::DBI should be able to do the right thing). If no such =
has=5Fa() declarations can be found, or none link to us, we assume that =
it is linking to us via a column named after the moniker() of our class.=
 If this is not true you can pass an additional third argument to the ha=
s=5Fmany() declaration stating which column of the foreign class referen=
ces us."

When MyApp::Entity->has=5Fmany(products =3D> 'MyApp::Product') is called=
, CDBI goes looking for MyApp::Product, can't find it and incorrectly as=
sumes that the moniker (MyApp::Product->entity()) references MyApp::Enti=
ty, giving me the above error. This is borne out by the fact that changi=
ng the table names so that product is loaded before entity makes everyth=
ing work.

Although all my manually defined model classes and their relationships d=
o not reside in the same file, I *think* Class::DBI::Loader is causing t=
he problem because it evals a "package ... " statement to create a class=
 for each table. I'm not certain, but I think this has the same effect a=
s all packages being defined manually in a single file - e.g. the requir=
e() mechanism, which would sort the dependencies out, is not used.

Maybe I could patch Class::DBI::Loader to do things a bit differently an=
d use require() to check whether a package for each table already exists=
 and if so manipulate that instead of running a 'package ..' statement. =
Again I'm not sure, but I think that would work.

Any ideas=3F

WH