On 7/25/07, Luke Opperman <[EMAIL PROTECTED]> wrote: > It's missing something, presumably you want to return the traversed FKs (or > their .q expression) in addition to the classes found in the search (building > the expressions as X.id == Y.id will not get the results intended, you want > X.fkToYID == Y.id). I'd probably let .q handle more of the work in > BuildJoinExpression too, so for instance:
Thanks for the advice, I didn't like having to drop down in sqlbuilder. Using .q makes it a lot more readable. > --- > > Using .q notation for traversing Joins and FKs is in trunk, so the > non-automated > way to address your problem is much simpler now: > > Foo.select(AND(Foo.q.bar, Bar.q.blah), orderBy=Blah.q.sortme) > > or equivalently if you define the matching SQL*Joins: > > Foo.select(AND(Bar.q.foos, Blah.q.bars), orderBy=Blah.q.sortme) Do you still have to specify all the intermediate tables? I have one join I need to make that uses 5 tables (and I would prefer to avoid thinking about the relational chain if I can). Plus if you change your relational structure, can the AND method appropriately adapt at runtime? Or is it fixed whenever you write it? Thanks, Brian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
