[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