[Dbix-class] Naming columns in nested joins

[Matt S Trout]

Jon wrote:
>     Basically, yes, you're supposed to keep track of it. Having a regular,
>     simple rule for how relationships get aliased a second or third time
>     means that you can always predict accurately what a given table in the
>     query is going to be called, and means DBIC can always predirect it
>     accurately as well. It takes a little bit of getting used to but once
>     you have you'll find you don't have to think about it any more, and it
>     ensures that DBIC can do all the magic it always does under the hood
>     without trying to keep track of names its been given (which would be
>     complex and potentially extremely fragile).
> 
> 
> 
> Makes sense. I just got a bit confused  since it was sort of 
> unabstracting away the sql (imho) but I see the stability problems.

The DBIC search syntax is effectively an SQL abstract syntax tree; if 
you want to maintain total abstraction for client applications, adding 
(and documenting :) a custom resultset class with additional search 
methods that hide these implementation details is the way forwards.