[Catalyst] CatalystX::CRUD

Peter Karman peter at peknet.com
Mon Sep 24 16:23:11 GMT 2007



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...).

> 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.

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');


-- 
Peter Karman  .  peter at peknet.com  .  http://peknet.com/




More information about the Catalyst mailing list