[Dbix-class] RE: joined table aliases

Byron Young Byron.Young at riverbed.com
Fri Jan 30 22:39:34 GMT 2009


Byron Young wrote on 2009-01-30:
> Hi,
> 

[snip]

> As you can see, hostname_2.name is not included as a column and
> it's not searched on.  Is there a good way to get around this?
> 
> Thanks,
> Byron


I did some more searching through the list archives and found this thread from Oct 2007: 

http://www.grokbase.com/thread/m/2007/10/29/dbix-class-second-join-gets-eaten-in-merge-attr/wO6Zjape9hEkNftHXhagJuUVW6M#wO6Zjape9hEkNftHXhagJuUVW6M

with the following exchange in it:

Matt S Trout wrote:
> On Tue, Oct 30, 2007 at 09:22:59AM +1100, brett gardner wrote:
>   
>> I don't think its as simple as that.
>>
>> I recently had to implement this behaviour and realised that in some
>> cases you might need to rename the columns in the query. eg
>>
>> $rs->search({'foo.bar_id' => 2},{join=>'foo'});
>>
>> then later
>>
>> my $new_rs = $rs->search({'foo.bar_id' = 45},{join=>'foo'});
>>
>> which would result in the query
>>
>> SELECT ....
>> FROM tbl1 LEFT JOIN foo ON (...)
>> LEFT JOIN foo foo2 ON (...)
>> WHERE
>> foo.bar_id = 2 AND foo.bar_id = 45
>>
>> Which is incorrect. as the second search clause should be "foo2.bar_id =
>> 45".
>>     
>
> It is. But it's also a completely different problem, and one that's much
> harder to solve - I hope to find a way to allow DBIC to instrospect on
> the query tree sufficiently to handle this case intelligently as part of
> our refactor of SQL::Abstract - interested in helping?
>
>   

I take it this is a known limitation.  Was the SQLA refactor that Matt refers to ever done, or any other solution developed?

Thanks again,
Byron



More information about the DBIx-Class mailing list