What’s the type of `request` in an exception view?

[jens.t...@gmail.com]

Hello,

I’ve got the following exception view:

@view_config(

    context=Exception,

    permission=NO_PERMISSION_REQUIRED,

    )

def handle_exception(exc, request):

    """Last resort view function."""

    …

I had assumed that the `request` parameter here is the same instance as the `request` parameter from the view function that raised the exception. However, that does not seem to be the case. (In fact, the SQLAlchemy session bound to the view function’s request has been expired by the time the exception view is entered.)

While a normal view function’s `request` parameter is of type pyramid.request.Request, the exception view’s is of type pyramid.util.Request. Which doesn’t seem to exist though: AttributeError: module 'pyramid.util' has no attribute 'Request'

It would be helpful if the docs would shed more light on this. Any more details would be great!

Thanks!

Jens

[jens.t...@gmail.com]

After some more tinkering: the `request` parameter is of type pyramid.util.Request which is derived from pyramid.request.Request, so using isinstance() is safe.

As per this example, my request instances have a user attribute which is a SQLAlchemy ORM instance tied to the request’s db session (see here). The odd thing that I’ve observed in the exception view is the following: sqlalchemy.inspect(request.user).detached is False, but then request.user.profile raises an exception.

I have to mention that the exception that enters the exception view is a sqlalchemy.exc.IntegrityError, i.e. the db session has been rolled back at the time when the exception view is entered. Should I check the db session’s is_active attribute inside of the exception view function, i.e:

def handle_exception(exc, request):
    if request.dbsession.is_active:
        # Safe to use request.user.
    else:
        # The exception raised in a view function caused the DB session
        # to flush or roll back--either way it's not usable anymore.

Thanks!

[Bert JW Regeer]

During exception handling pyramid_tm will have already rolled back, and the database session is no longer valid for use. Any access will cause sqlalchemy to raise.

Please verify you are using the latest version of Pyramid and pyramid_tm, and then read this note: https://docs.pylonsproject.org/projects/pyramid_tm/en/latest/#error-handling

You ay need to change your exception handling to match the new requirements in the newer versions of pyramid_tm.

Bert

-- 
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/2f922a5b-a325-4bf3-9bea-81cdf4f974d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.