[Catalyst] Returning error codes to the user.

[Bill Moseley]

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'                 =3D> $requested_user_id,
        'me.active              =3D> 1,
        'me.date_expires'       =3D> [
            { '>' =3D> \'now()' },  # past expired
            { '=3D' =3D> undef },     # or never expires
        ],

        'account.active'        =3D> 1,
        'account.balance'       =3D> { '>' =3D> 0 },
        'account.locked'        =3D> 0,
        'account.date_expires'  =3D> [
            { '>' =3D> \'now()' },  # past expired
            { '=3D' =3D> undef },     # or never expires
        ],
    },
    {
        join =3D> '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.]

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?

Just like our favorite topic premature optimization, I don't think it would
be wise to write the above in multiple stages (and multiple requests to the
database) just to check each step for something that almost never fails.

On the other hand, it's not unreasonable for an API request to return a
reason why something failed.  Sure would make tech support's life easier.


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?



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100430/c279b=
7c0/attachment.htm