[DBIx-Class-Devel] Pull Request: topic/docs-pod-inherit

[Peter Rabbitson]

On Tue, Dec 11, 2012 at 03:12:12PM -0500, Brendan Byrd wrote:
> On Tue, Dec 11, 2012 at 2:57 PM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> > On Tue, Dec 11, 2012 at 02:45:53PM -0500, Brendan Byrd wrote:
> >> It's a shame that it's problematic to implement, as it would be nice
> >> to have some sort of virtual_view type View class that doesn't require
> >> knowledge of SQL to implement.  I will also redirect users to the View
> >> docs as an alternative to rs_attr, since many of the asks around that
> >> could be solved via View.
> >
> > I may be missing something here - can you give me an example/use case
> > (pseudocode ir whatnot) of such a "virtual_view without knowing SQL".
> > Then I probably will be able to give a more convincing answer.
> 
> Well, in the gist I linked above, the guy was trying to basically link
> two tables together and always have the data prefetched.

Never say never... I mean never say always ;)))

In ResultSet::Foo:

...

sub with_bars { shift->search({}, { prefetch => 'bar' }) }

Then in his code

$schema->resultset('Foo')->with_bars->...rest as usual

> One of my solutions was to just have the two tables joined as a View, 
> but view_definition requires knowledge of SQL to implement.

A view implies a single resultsource. A single source implies a single
result object. This will entirely break the concept of prefetch, which is
specifically designed around the idea of
my $related_source_object = $oject->single_relationship

> It would be nice if you could define view_definition in the form of a
> search() param.  DBIC would recreate the SQL, and then use that for
> the View definition.

This is how $rs->as_subselect_rs works no?