On Sun, Oct 25, 2009 at 6:54 AM, Peter Rabbitson <[email protected]<rabbit%[email protected]> > wrote:
> > > > 1) Create a virtual view resultsource, and give it a specific result_class > via ->resultset_attributes (which will add the result_class setting to > every > resultset class spawned from the virtual source) > > I'm not sure how practical that approach is. I've always thought of the virtual views being of limited use for custom SQL. I tried this approach for this specific problem. I did set the "result_class" attribute and indeed got objects blessed into that class. But, they didn't not function as those objects -- namely I could not call relationship methods. I suppose the relationships can be defined in the virtual view class, but that's not very DRY if I have a large number of custom SQL views for the same result class. Is there a way to make the custom views act just like the result class? I would find it more "natural" to define the custom SQL in my ResultSet classes -- so that I could do: @artist = $schema->resultset( 'Artist' )->outside_gigs; But, I guess outside_gigs() can always proxy to the virtual view. Again, it's not much use if the resulting objects don't act just like a normal Artist object where relationships still work. Thanks again for your help, Peter. -- Bill Moseley [email protected]
_______________________________________________ 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]
