> > which is why I keep badgering him to weigh in on this issue only. >
sorry, i feel a bit clearer on what you want to hear now. for this particular need, the others tabled, it's largely testing and troubleshooting -- and it is a bit more advanced. things we've used that key for in the past and present: - unit and integrated tests that handle how session data is stored / persisted. ensuring it is saved across requests on the backend store and validating the backend store directly. it's a silly thing on one machine, but when you have a cluster of machines and start experimenting with Master/Slave replication, issues come up. without exposing this identifier, one needs to trust some unseen "magic" that everything is being persisted correctly, and then do subsequent requests to see if data is being pulled out correctly. i can't easily save a session and confirm how it has saved on memcached/redis ; I need to save a session and then load the session on a new request. - this also simplifies tests that ensure we have loaded the correct session or unloaded/create a "new" one. the boolean 'new' loses utility if you invalidate/create multiple sessions in a single request. chris' suggested `get_session_uuid` would handle this. - this use case borders on a tabled discussion, but accessing the session_id allows us to more easily identify and load particular sessions, and create test cases around them. for example, we may deploy some new code that stores/handles particular bits of session data differently... and that has broken some routes in the past. by knowing the session_id, we can alter the actual backend data store to create "broken" sessions in the backend, and then use unit-tests / TDD to handle the issues gracefully. - admin / troubleshooting / support - being able to identify the internal id on a first request, so it can be cross-loaded into other requests ( not as a session, but as a raw data-stash pull ); we also have exception tweens that automatically log the exceptions, session_id and a snapshot for later examination. while an internal UUID can be logged , it can't be reliably used to 'load' data off the backend (session backends aren't necessarily full-text searchable; many are k/v pairs ) the other things we've used it for can be replaced by an "internal uuid" or a secondary cookie which is used as tracking identifier; however that does create the need to duplicate work and increase the amount of cookies or cookie storage. being able to access the session_id allows for a lot of savings in workload and transmission -- but the big utility is in being able to log and confirm where data is saved to. also, just to re-iterate, i'd be fine if this particular request weren't a "requirement" but a "suggested implementation". if ISession doesn't support it natively, fine. BUT if people build plugins that use an internal session key , there should be an official/recommended method on how to expose it. sort of like dirty-needle programs for drug addicts: if you're going to do it, do it this way. however - I don't think the potential drawbacks of the 'may return None' situation is substantial. i can only see it being an issue in two scenarios : a_ the cookie is client side b_ the plugin hasn't supported the session_key yet. There could be others, but those are the only ones i see. if the cooke is client side, there is no session_key. the programmer should never have accessed session_key. if a session_id is needed, docs could instruct the usage of 'get_uuid' or creating an ancillary tracking cookie. if the plugin hasn't supported the session_key yet, then - 1) there aren't many open source pyramid session packages. patches and update to 90% would be relatively quick. 2) if there is a private session package, the developer would be calling a function that they haven't provided for yet. @Randall-- for your use-case, I would probably use something like chris' suggestion -- where you have a set/get uuid function that accepts an explicit session. we run 2 sessions simultaneously -- the normal `request.session` (which is an encrypted client-based-session) and a `request.session_https` that implements a server-side session locked down to https traffic ( it's just pyramid_beaker forked and bound to SSL and a different request attribute ). we have code that operates on specific request attributes, but also other code that accepts and explicit session object. if you have the potential for conflicts -- 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/d/optout.
