On Tue, Jun 30, 2009 at 11:14, David Ihnen<[email protected]> wrote: > But the question seemed to be 'I don't understand why you would need this' > and 'is there a need for this feature' and I must vociferously respond "IT > IS USEFULE" and "YES THERE IS". As for 'is there a need to do it this way' > to which I'd agree with you, probably not this way, its awfully cludgy to > use the refs. > > BTW, I am okay with the join terms *not* being query time dynamic/bindable > stuff - in my application I want to join based on two separate relations > between the two tables, not just one, and not using a query-time parameter > that affects the relationship spec.
I don't think anyone has said "This is a bad idea." For my part, I've been pushing back to try and get some use-cases that cannot be written as methods or rewritten with subqueries. My point in all this is that relationships should be created when you want to use that join in a query later or via X_related(). Otherwise, it's nothing more than an auto-generated method that returns a resultset against another table with a where condition set for you. I think that a lot of people are trying to create relationships where a relationship may not be appropriate. Just chain resultsets! Now, if someone can provide a solid use-case, then I'll be onboard. But, adding features for the sake of adding features is how you end up with a crappy API. Rob _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
