column_type_classes and "method already exists"

[Daniel Green]

I have the following column_type_classes call in my own
Rose::DB::Object::Metadata subclass:

__PACKAGE__->column_type_classes
(
char => ' ACME::DB::Object::Metadata::Column::Character',
character => 'ACME::DB::Object::Metadata::Column::Character',
varchar => 'ACME::DB::Object::Metadata::Column::Varchar',
string => 'ACME::DB::Object::Metadata::Column::Varchar',
text => 'ACME::DB::Object::Metadata::Column::Text',
);

At some point during initialization (no loading yet far as I can tell)
I receive an error message like...

Cannot create method ACME::DB::SomeTable::some_column_name - method
already exists at /opt/acme-perl/perl-5.12.2/lib/site_perl/5.12.2/Rose/
DB/Object/Metadata/MethodMaker.pm line 426

MethodMaker.pm is $VERSION = '0.769'

If I get rid of mappings such that each value is unique (for example,
remove "string" and "char"), I do not get this error.

I have also tried setting columns with column_type_class one by one
instead of as a hash.

Is this enough information to expose that I've done something horribly
wrong?

[John Siracusa]

On Thu, Jan 12, 2012 at 12:02 PM, Daniel Green <octob...@gmail.com> wrote:
> At some point during initialization (no loading yet far as I can tell)
> I receive an error message like...
>
> Cannot create method ACME::DB::SomeTable::some_column_name - method
> already exists at /opt/acme-perl/perl-5.12.2/lib/site_perl/5.12.2/Rose/
> DB/Object/Metadata/MethodMaker.pm line 426

That looks like a class being set up more than once. Circular module
dependencies maybe? I'm not sure why the column_type_classes map
would affect that. I suggest trying to boil it down to a minimal test
case.

-John

[Daniel Green]

Ah. Perhaps this answers it: http://osdir.com/ml/lang.perl.modules.dbi.rose-db-object/2005-12/msg00064.html

[Daniel Green]

I was wrong before about the values needing to be distinct in order
for it to work. It looks like remapping 'character' is what breaks it.

On Jan 12, 12:08 pm, John Siracusa <sirac...@gmail.com> wrote:

[Daniel Green]

> > > At some point during initialization (no loading yet far as I can tell)
> > > I receive an error message like...
>
> > > Cannot create method ACME::DB::SomeTable::some_column_name - method
> > > already exists at /opt/acme-perl/perl-5.12.2/lib/site_perl/5.12.2/Rose/
> > > DB/Object/Metadata/MethodMaker.pm line 426
>
> > That looks like a class being set up more than once. Circular module
> > dependencies maybe? I'm not sure why the column_type_classes map
> > would affect that. I suggest trying to boil it down to a minimal test
> > case.

I was able to isolate the problem and confirm that there were no
circular dependencies. The foreign key relationship appears to be the
key to the bug. I am not sure what to do about it though.

#
# For table foo
#
package ACME::DB::Foo;
...
__PACKAGE__->meta->setup
(
columns => [ code => { type => 'character' } ],
primary_key_columns => ['code']
);
...

#
# for table bar
#
package ACME::DB::Bar;
...
__PACKAGE__->meta->setup
(
columns => [ baz_qux_code => { type => 'character' } ],
foreign_keys =>
[
baz_qux_code =>
{
class => 'ACME::DB::Foo',
key_columns { baz_qux_code => 'code' }
}
]
);
...
);

[Daniel Green]

My assumption is that I need to fiddle with ConventionManager since we
are using "code" as the primary key and not "id". This is what I
gleaned from the mailing list response I linked to. However, I can't
figure out how this relate to customizing columns?

[John Siracusa]

On Thu, Jan 12, 2012 at 2:32 PM, Daniel Green <octob...@gmail.com> wrote:
> I was able to isolate the problem and confirm that there were no
> circular dependencies. The foreign key relationship appears to be the
> key to the bug. I am not sure what to do about it though.

Well, you've reproduced the "don't name your fks or rels the same as
your columns" bug, but if that's your actual bug you can just rename
your fk/rel(s), no?

-John

[Daniel Green]

> On Thu, Jan 12, 2012 at 2:32 PM, Daniel Green <october...@gmail.com> wrote:
> > I was able to isolate the problem and confirm that there were no
> > circular dependencies. The foreign key relationship appears to be the
> > key to the bug. I am not sure what to do about it though.
>
> Well, you've reproduced the "don't name your fks or rels the same as
> your columns" bug, but if that's your actual bug you can just rename
> your fk/rel(s), no?
>

Renaming the relationship fixed the problem delightfully. However, why
would this condition only occur if I do the remapping? Maybe calling
add_builtin_trigger causes some loading that wouldn't have happened
previously?

On Jan 12, 2:42 pm, John Siracusa <sirac...@gmail.com> wrote:

[John Siracusa]

On Thu, Jan 12, 2012 at 3:03 PM, Daniel Green <octob...@gmail.com> wrote:
> Renaming the relationship fixed the problem delightfully. However, why
> would this condition only occur if I do the remapping? Maybe calling
> add_builtin_trigger causes some loading that wouldn't have happened
> previously?

Maybe the error is happening in both cases, but it's being eaten by a
stray eval block somewhere in one of the cases?

-John