On Sun, May 2, 2010 at 12:53 PM, Matt S Trout <m...@shadowcat.co.uk> 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 mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/