Re: [Catalyst] Returning error codes to the user.
On Sat, May 1, 2010 at 6:17 PM, Tomas Doran bobtf...@bobtfish.net wrote: So, what would you recommend? Have a separate /user/$id/debug method that does a separate step-by-step of the business logic? Scrap all that really handy chaining of resultsets that works so well with Catalyst's chained actions? Given that 'a tiny, tiny percent a request might fail', why not do the step by step for the tiny failed set and then present the reason to the user for those? (Or am I missing something obvious here?) You are not missing anything if that's your recommendation. I assume lots of people here are creating real web applications with Catalyst so was inquiring how others handle this situation in the design of their applications. I have a CRUD controller base class to help generate a RESTful-like API that is used by both API users and with an AJAX-based application, which I assume is not that uncommon with Catalyst apps. For example, when a PUT /thingy/52113 fails (which means the query used to fetch the item failed), how do you reported to the user? A 404 with a text description? Some kind of error code in the response body? I my case, I'm added a method explain_not_found() to the base class that can be overridden in the controller to provide specific details in textual format. That method would be used to break the query into parts to test each join and condition, for example. As a side note: Frankly, I enjoy the discussions of real problems and solutions on this list. I try not to find it discouraging that old topics like benchmarking methods calls and the few inflammatory remarks seem to get so much traction. :) -- 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/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
On Fri, Apr 30, 2010 at 02:38:50PM -0700, Steve Kleiman wrote:
Here goes...hopefully a simple test case for the RunAfterRequest oddness.
The code below with the forward INSIDE 'run_after_request' subroutine throws
the error:
[error] Caught exception in engine Modification of non-creatable array
value attempted, subscript -1 at
/usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278.
I think that's probably $c-stack being empty because there's no request
anymore.
I *think* that
$c-view('Email')-process($c);
would work, since that doesn't rely on the action call stack.
That error message is fucking awful though, and almost certainly my fault.
Proposal: first you try the -process-by-hand approach to confirm that I'm
an idiot the way I think I am. Second we discuss how to either (a) fix this
or (b) make sure it produces a non-awful error.
(even if you've already rewritten the code it'd be much appreciated if you
could try this out and see if it does the right thing - also, you then get to
point and laugh at me with a bit of luck, which may or may not be an added
incentive ;)
--
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/
Re: [Catalyst] Returning error codes to the user.
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/
Re: [Catalyst] Returning error codes to the user.
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/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
Wow, Matt. That works like a charm. THANK YOU.
No pointing and laughing from this corner. Except at myself for not setting up
a proper email dispatching mechanism. One bridge at a time.
Again, my thanks for tracking that down.
Steve Kleiman
st...@prodhub.com
On May 2, 2010, at 12:49 PM, Matt S Trout wrote:
On Fri, Apr 30, 2010 at 02:38:50PM -0700, Steve Kleiman wrote:
Here goes...hopefully a simple test case for the RunAfterRequest oddness.
The code below with the forward INSIDE 'run_after_request' subroutine throws
the error:
[error] Caught exception in engine Modification of non-creatable array
value attempted, subscript -1 at
/usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278.
I think that's probably $c-stack being empty because there's no request
anymore.
I *think* that
$c-view('Email')-process($c);
would work, since that doesn't rely on the action call stack.
That error message is fucking awful though, and almost certainly my fault.
Proposal: first you try the -process-by-hand approach to confirm that I'm
an idiot the way I think I am. Second we discuss how to either (a) fix this
or (b) make sure it produces a non-awful error.
(even if you've already rewritten the code it'd be much appreciated if you
could try this out and see if it does the right thing - also, you then get to
point and laugh at me with a bit of luck, which may or may not be an added
incentive ;)
--
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/
___
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/
