On Sun, May 2, 2010 at 12:53 PM, Matt S Trout <[email protected]> wrote:
>
> Am I correct in thinking that's built up in multiple ->search calls?
>
Somewhat, yes.
>
> ... if you keep all the intermediate resultsets around in the stash or
> wherever (or better still refactor to resultset methods and have your
> custom resultset class keep the intermediate resultsets around) then it
> seems like it should be pretty easy to walk back up the chain making
> the extra queries until one returns data - at which point you know the last
> step you walked back up is the problem child for this request.
>
That's an interesting idea. So, instead of adding multiple constraints in a
single call to search I could do it individually.
I'm not sure if I need to subclass the resultset_class -- could just add a
controller base class method. i.e.:
$self->add_to_resultset( $c,
'User account must be active',
{ me.active => 1 },
);
$self->add_to_resultset( $c,
'User account expired',
{ 'me.date_expires' => [
{ '>' => \'now()' }, # past expired
{ '=' => undef }, # or never expires
],
},
);
$self->add_to_resultset( $c,
'Parent account must be active',
{ 'account.active' => 1 },
{ join => 'account' },
);
etc.
Then, as you say, if $self->current_resultset->first (top of stack) fails
then work down the stack until find the spot where the query passes and
return the previous message.
Thanks,
--
Bill Moseley
[email protected]
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
