On Fri, Apr 30, 2010 at 04:18:46PM -0700, Bill Moseley wrote: > I have a CRUD interface to an application. This is used for both the Web > and directly as an API. > > The model uses DBIC which, as you know, allows chaining resultsets, which I > use to add additional constraints to the result set. > > So, a request for, say, /user/1234 might result in: > > $c->model( 'App::User' )->search( > { > 'me.id' => $requested_user_id, > 'me.active => 1, > 'me.date_expires' => [ > { '>' => \'now()' }, # past expired > { '=' => undef }, # or never expires > ], > > 'account.active' => 1, > 'account.balance' => { '>' => 0 }, > 'account.locked' => 0, > 'account.date_expires' => [ > { '>' => \'now()' }, # past expired > { '=' => undef }, # or never expires > ], > }, > { > join => 'account', > }, > ); > > [That's not a great example because we assume that "user" and "account" > might get checked when first logging in. Ignore that. Just assume a query > that does a lot of joins to test if a given object can be accessed.]
Am I correct in thinking that's built up in multiple ->search calls? If so ... > The request either succeeds (200) or fails (404). > > The VAST majority of the time the ID provided will return a row because a > valid ID was provided by the application itself in the first place. > > But, for a tiny, tiny percent a request might fail. Then the question is > *why* did it fail? What WHERE condition or join failed? ... 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 way you get to only make the extra queries in the failure case, for minimal extra code - basically taking advantage of DBIx::Class' laziness coming -and- going :) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team. _______________________________________________ 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/