<br><div><span class="gmail_quote">On 5/24/06, <b class="gmail_sendername">Matt S Trout</b> <<a href="mailto:dbix-class@trout.me.uk">dbix-class@trout.me.uk</a>> wrote:</span><div><br>[snip] <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="http://search.cpan.org/~jrobinson/DBIx-Class-0.06003/lib/DBIx/Class/ResultSet.pm#join">http://search.cpan.org/~jrobinson/DBIx-Class-0.06003/lib/DBIx/Class/ResultSet.pm#join</a><br><br>"If the same join is supplied twice, it will be aliased to <rel>_2 (and
<br>similarly for a third time)."</blockquote><div><br>Umm, ok. That's what you get for not RTFM :)<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Basically, yes, you're supposed to keep track of it. Having a regular,<br>simple rule for how relationships get aliased a second or third time<br>means that you can always predict accurately what a given table in the<br>query is going to be called, and means DBIC can always predirect it
<br>accurately as well. It takes a little bit of getting used to but once<br>you have you'll find you don't have to think about it any more, and it<br>ensures that DBIC can do all the magic it always does under the hood<br>
without trying to keep track of names its been given (which would be<br>complex and potentially extremely fragile).</blockquote><div><br><br>Makes sense. I just got a bit confused since it was sort of unabstracting away the sql (imho) but I see the stability problems.
<br><br>/Jon <br></div><br></div>