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
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.
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
On 30 Apr 2010, at 23:18, Bill Moseley wrote:
But, for a tiny, tiny percent a request might fail. Then the
question is *why* did it fail? What WHERE condition or join failed?
Just like our favorite topic premature optimization, I don't think
it would be wise to write the above in
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(
