-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request's storage #242
Comments
how about Request(dict) same as Application? |
I used to reject your idea before publishing the issue, but after rethinking I agree with you. The same approach looks good. |
Fixed in da0bd63 |
You commit too quickly to have the time to react ;-) |
Sorry for that but I had have a feel that we are on the same point On Wed, Jan 14, 2015 at 11:00 PM, Ludovic Gasc notifications@github.com
Thanks, |
Don't worry, you're right ;-) |
Thinking on adding sessions to aiohttp.web I'we found that may be implemented as separate project.
API would be like:
The session object may be implemented as Pyramid does (I just guess to borrow the code from aiorest: https://github.com/aio-libs/aiorest/blob/master/aiorest/session/base.py#L9).
Session loading and storing may be implemented by session middleware.
But I need the way to get session object from web-handler.
The most native way is storing session object in request by middleware on loading.
Those I guess to add
request.storage
property which is a regular python dict. Middleware may store the session in the dict under, say,'aiohttp_session'
key -- and user may return it back byget_session()
call.The same technique may be used, say, for saving database transaction for committing uncommitted transactions on web-handler finishing (and rolling back on exception from web-handler).
Another options is to save session as
request._session
(we use it for now but I don't like changing request's namespace, it should be considered as constant object).The third option is to use global dict with
Request
objects as keys, but I hate singletons.The fourth is to add
Request.set_property()
as Pyramid does but I personally don't like the idea of mutating the list of request public properties on request's execution. That may make a mess easy.Resume: I propose to add per request dict storage (as well as we already have per application one) and allow to third-party libraries to make accessors to that storage if needed.
The text was updated successfully, but these errors were encountered: