"B" just needs some cookbook examples. And I think Pyramid's session > infrastructure needs to support session IDs. Not as a requirement for > all backends, but as support for the backends that want it so they > don't all have to reinvent the wheel. I'd like the 'session.id' > attribute to be standard, although that may be too much. (Currently, > my code uses 'getattr(session, "id", None)' to determine the session > ID and whether the backend supports that kind of ID. Perhaps it should > be 'session["id"]'; I'm not sure, but Beaker uses 'session.id' and I > think pyramid_redis_sessions does (?). >
+100 I created an issue 12 months ago, which was rejected and closed -- https://github.com/Pylons/pyramid/issues/895 ISession needs to support proxying the session id from backends that support it. The two problems I had with implementing B was, one, figuring out how > Beaker manages the session ID, and two, the number of subtables I'd > have to add. Session data tends to me more hierarchical than regular > model data in my experience. For searches I have to store the criteria > (multiple fields), the result IDs (a list), flash messages (a list or > type:list queues). So my two-table application would explode to five > or six tables, plus configuring all the relationship attributes. I > started to do it but it got so complicated I went back to Beaker > because it's working (and I'm now heading toward > pyramid_redis_sessions). > Well another strategy would be to do everything in a single table. Personally I wouldn't want to have so many tables. Imagine if you had an encrypted cookie that contained this (and had a timestamp to time out after 30 minutes ) user_id : INT for authenticated user, NULL for no user session_id : random hash (pseudocode): class SessionDataUser(sqlalchemy): session_id INT session_data TEXT class SessionDataFlow(sqlalchemy): session_id INT session_data TEXT If you have a user_id , you pickle/unpickle "SessionDataUser", which can be used across devices. this lets you precalculate expensive data only once per user and persist info across browsers. For both users, you pickle/unpickle "SessionDataFlow" , which just has flash messages or search data, etc ; stuff that is relevant to the current flow -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out.
