-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: