[Dbix-class] Duplicate me.id in WHERE clause of simple query

[Rob Kinyon]

On Tue, Jan 25, 2011 at 12:49, Alan Humphrey <alan.humphrey at comcast.net> 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