Re: Re: field names and Class::DBI

Thanks! This worked.

Just to clarify. The documentation says:

When setting up the relationship we examine the foreign class's has_a() declarations to discover which of its columns reference our class. If no such declarations are set up, or none match, 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 has_many() declaration stating which column of the foreign class references us.

In my case the other table does have the has_a() declaration - so it should work the way I wrote.

Comment on Re: Re: field names and Class::DBI

Replies are listed 'Best First'.
Re: Re: Re: field names and Class::DBI by bart (Canon) on Feb 19, 2004 at 17:09 UTC
No... don't forget that `has_many`() and `has_a`() are actually method calls, not declarations... so they are executed in the order that they are in the source code. The `has_many`() call comes first, and at that time, the `has_a`() call hasn't happened yet. If you were to reorder your source code so that the `has_a`() call comes first, then it would indeed have to work. So, what happens now? Class::DBI makes a bad guess, it uses the "moniker" of the class name that has the `has_many`() call, for the field name for the remote table. In your case, that is "`usr`", derived from the class name "`Dl::Usr`".	[reply]

Replies are listed 'Best First'.

Re: Re: Re: field names and Class::DBI
by bart (Canon) on Feb 19, 2004 at 17:09 UTC

has_many

has_a

executed

has_many

has_a

If you were to reorder your source code so that the has_a() call comes first, then it would indeed have to work.

So, what happens now? Class::DBI makes a bad guess, it uses the "moniker" of the class name that has the has_many() call, for the field name for the remote table. In your case, that is "usr", derived from the class name "Dl::Usr".

[reply]