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. _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
