On Tue, Jan 25, 2011 at 12:49, Alan Humphrey <[email protected]> wrote: > Coincidentally, I just saw this behavior. > > The trick seems to be setting up a belongs_to relationship where the > relationship name is the name of the foreign key: > > __PACKAGE__->belongs_to( 'order_id', 'BirdWeb::BirdWebSchema::Orders'); > > or > > __PACKAGE__->belongs_to( 'order_id', 'BirdWeb::BirdWebSchema::Orders', > 'order_id'); > > Then use the relationship name: > > $family->order_id->order_scientific_name > > If you prefetch the relationship there's no problem. If you use a different > name for the relationship there's no problem. > > And, as Winni originally reported, the problem is an extra 'me.id' in the > generated SQL: > > SELECT me.id, me.order_scientific_name, me.order_common_name, > me.order_description, me.order_navigation_name, me.taxonomic_order, > me.species_worldwide, me.species_north_america, me.species_washington, > me.families_worldwide, me.families_north_america, me.families_washington FROM > orders me WHERE ( ( me.id = '9' AND me.id = '9' ) )
Although this advice wasn't because of avoiding this bug, it's generally considered to be a "Bad Plan"™ to make a relationship name the same as the foreign-key column you're using to fetch on. Instead of $family->order_id->order_scientific_name, it should be something like $family->order->scientific_name. There are lots of reasons you might want the order_id itself. And, always prefetching something without knowing you're going to need it is just . . . icky. So, in other words, sanitary practices would avoid this bug. Rob _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
