Knocking meekly on the gates the lowly monk creeps forward, hoping his brethren can help save his sanity.

We're learning about Class::DBI, and have mocked up some samples to see if it meets our needs. So far, it all seems excellent, but I've hit a snag I can't understand.

The issue seems to be some interaction between many to many relationships and overriding the standard accessor names. In the base class that derives from Class::DBI (which all our other classes then derive from), we have the following:

   sub accessor_name {
      my ($_class, $_column) = @_;

      my $_accessor = $_column;
      $_accessor = ucfirst $_accessor;
      $_accessor = 'Get' . $_accessor;
      $_accessor =~ s/id$/Id/smx;
      return $_accessor;
   }

   sub mutator_name {
      my ($_class, $_column) = @_;
      my $_mutator = $_column;
      $_mutator = ucfirst $_mutator;
      $_mutator = 'Set' . $_mutator;
      $_mutator =~ s/id$/Id/smx;
      return $_mutator;
   }
[download]

This makes all accessors and mutators follow our standard naming convention. So far, so good, it works as expected.

Now we have a many to many relationship between classA and classB. This is done using a table tableClassAtoB. The problem comes when we do the following:

my $classBItr =  $classA->classBs();
while ( my $b = $classBItr->next() ) {
  ...
}
[download]

When the next() is executed, we get the error:

Can't locate object method "classB_id" via package "ClassAtoB" at /usr
+/lib/site_perl/5.8.5/Class/DBI/Iterator.pm line 77.
[download]

Due to how we've overriden the accessor name, it's clear to me that the method classB_id doesn't exist. We've used the Class::DBI functionality to change it to ClassB_Id(). But apparently Class::DBI::Iterator does not know that.

What are we doing wrong? Do we need to subclass the Class::DBI::Iterator and create our own?

Thanks Monks!