[Catalyst] CatalystX::CRUD

[Matt S Trout]

On Mon, Sep 24, 2007 at 10:23:11AM -0500, Peter Karman wrote:
> 
> 
> On 09/23/2007 11:24 AM, Matt S Trout wrote:
> > On Fri, Sep 21, 2007 at 08:57:35AM -0500, Peter Karman wrote:
> 
> >> CXCM subclasses would need to implement at least the following methods:
> >>
> >>  * new_object  - returns CatalystX::CRUD::Object->new()
> >>  * fetch       - returns CatalystX::CRUD::Object->new()->read()
> >>  * search      - returns zero or more CXCO instances as an arrayref
> >>  * interator   - like search() but returns an iterator
> >>  * count       - like search() but returns an integer
> > 
> > Have you looked at the way the Handel storage stuff works? That already
> > supports both DBIC and RDBO so might be an interesting start.
> > 
> 
> I have looked through it (I had to figure out that Handel-Storage-RDBO is
> packaged separately...) and it looks like the base Storage API is much more
> complex and full-featured than what I am suggesting. But all the methods I
> mention are there in one or another. I'll probably dig in to the DBIC
> implementation when/if I need help with that part of CXCM (/me hoping not write
> that all by myself...).

Yeah, don't blame you :)
 
> > Do you have any thoughts on how to paper over DBIC's ability to chain searches
> > vs. the lack of that feature in RDBO? I know most RDBO users don't feel
> > they're deprived not having it but DBIC users are generally fairly addicted :)
> > 
> 
> I've read about that feature difference in the mail archives, but since I
> haven't used DBIC myself, other than to just play for about an hour, I'm not
> sure what the equivalent RDBO code would look like. I do all kinds of multiple
> relationships in my RDBO code, where I chain together method calls to get at
> related data. Is the difference that RDBO might be making multiple db calls,
> whereas DBIC doesn't?
> 
> For example, in your reply to Perrin you used this example:
> 
> > This sort of thing in DBIC just becomes
> 
> > $posts_rs = $users_rs->search_related('posts');
> 
> In RDBO, if I wanted all the posts for a given user, I might just say:
> 
>  $posts = $user->posts;
> 
> So how is that different? Because $users_rs might represent multiple users? If
> so, yes RDBO would require something a little longer, like:
> 
>  map { push @posts, $_->posts } @$users;
> 
> Which, depending on if I pre-fetched the posts when creating $users, might end
> up being lots more trips to the db. And it doesn't give me $posts_iterator,
> which might be preferable to @posts.

The main diff here is the DBIC users_rs could represent many users without
ever actually fetching them.

Looking at your example though, I think I'm worrying too much.

> But I think for the purposes of this CatalystX::CRUD proposal, the harder
> issues are going to be abstracting the conversion of $c->params() to what gets
> passed to search(), iterator(), count(), etc. Right now that is all very
> RDBO-specific in CCR::Search.
> 
> Couldn't the whole DBIC search_related issue just be resolved by pushing the
> issue out into the controller and/or view space? In your CCR::Search subclass:
> 
>  my $results = $c->model('My::CatX::CRUD::Model::DBIC')
>                       ->search(@params)->search_related('foo');

I think we'd just end up providing traverse_related methods that did stuff.

The RDBO implementation might be a little less efficient than the DBIC one
but for the sort of workload we're looking at here it's probably -fairly-
academic performance-wise.

And if it's not, you can go bug siracusa until that changes :)

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/