On Thu, Dec 12, 2013 at 10:12 AM, Bert JW Regeer <[email protected]> wrote: > If you need server side sessions (and I would take some time figuring out why > you need them) take a look at pyramid_redis_sessions for example.
How can you store search state or the logged-in user without sessions? Sometimes you can replace sessions with cookies, but cookies have a size limit, can be arbitrarily modified behind your back (meaning you'd have to revalidate the data on every request), and you may have internal data you don't want to reveal directly to the client. The REST people always said sessions are bad but they never addressed an adequate alternative. You can store "session" data in database tables keyed by session ID, but session data is often more hierarchical than your regular database objects, so you'd end up either creating as many related tables as the rest of oyur application has or pickling it... and if you pickle it then that's essentially the same thing as a session except you have to write the code to fetch and save it yourself rather than having the session infrastrucure do it for you. > > > It has been mentioned that using dogpile.cache for sessions doesn’t make much > sense, see this comment by zzzeek: > http://techspot.zzzeek.org/2012/04/19/using-beaker-for-caching-why-you-ll-want-to-switch-to-dogpile.cache/#comment-532502543 In that case zzzeek gave an incorrect impression of what Dogpile would be. He said it would be a replacement for Beaker. The vast majority of Beaker users are using it for sessions, and only a few for caching. > Use a signed/encrypted cookie to have the session store off-loaded to the > client, or store the data into a database and use it WITH dogpile.cache to > provide caching as appropriate (sqlalchemy with dogpile.cache for example), > and return a cookie that contains a unique ID that associates it with the > database data. > Since a session is essentially a cache, I think a pyramid_dogpile would just be a matter of a Pyramid.ISession front end to dogpile.cache. I haven't looked at it closely but I think Pyramid has at least some of the support for the cookie part. I don't understand what the "lot of other work" zzzeek is referring to is. If we're going to transition people away from sessions, it should be done in a deliberate way with documentation and tutorials, not just letting the session infrastructure stagnate until it dies away, without even telling people it's going. Especially when Pyramid and Pylons have been recommending sessions for so many years. -- 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.
