On 05/08/2014 01:21 PM, Mike Orr wrote:
On Thu, May 8, 2014 at 4:16 AM, Chris McDonough <chr...@plope.com> wrote:
All of the above use cases presume that you have visibility into the session
implementation's backend to load data. If you do, that's fine, but there
are no APIs in Pyramid that provide this functionality, so you're already in
implementation-dependent mode when trying to satisfy any of them.
That's the point of this discussion: the API is missing a pretty
standard feature.
That may be true, but I'm sure you can see that session objects having a
uniform .id attribute won't solve the entirety of the problem implied by
the above complaint.
If you mean that being able to load session data using a session id is a
required feature, I'm pretty sure that ISession is not missing a
feature. You need to have a session object to use the ISession
interface, and you obviously can't get one without loading a session. So
when you say something like the above, I think you're really asking for
an additional interfaces e.g.
def session_id_from_request(request):
""" Return the session id of the current request """
def load_session(request, session_id):
""" Return the session object given the provided session id """
The conversation started by you and Jonathan insisting on "just" having
a uniform session id attribute on an already-loaded session object, but
AFAICT, and given everyone's descriptions of their problems, just having
that feature it just doesn't seem to make much difference in isolation.
The reasons given for wanting it seem to always imply wanting the
above APIs as well, or at least Jonathan hasn't provided any cases where
one or the other is not ultimately necessary to not need to read the
source code of the implementation.
Given your use cases, does it make maximum sense to have a uniform id
attribute on the session without having these APIs? If so, please help
me figure out how. But if we can't think of a compelling reason to have
session.id in isolation from something like the above APIs, then we have
to consider adding them as well. I'm pretty uninterested in adding
features to the interface that doesn't actually solve the real problem,
or leaves you needing to read the source code of each session
implementation anyway in order to go behind its back and read cookie
data from the request or session data from the backing store. That'd be
a half-solution that would only add confusion.
One compromise would be to add this function to pyramid.session:
def get_session_uuid(session):
""" Return the uuid associated with this session """
return session.setdefault('_uuid_', uuid4())
I'm not sure about that as a method, but another compromise would be
to document the pattern (i.e., the expression) in the session
documentation. That would give users something they could drop into
their code, and avoid reinventing it or searching the session source
code in vain.
It seems to me that the id is least of your worries in each case, or at
least it would be a lot simpler to just depend on a custom concrete ISession
implementation than it would be to churn the gears to mandate that all
session implementations expose an id attribute.
That puts the burden on the user! Not all users can figure out how to
make a working ISession implementation or modify
'pyramid_redis_sessions', and it takes a lot of time.
You're willing to read pyramid_redis_sessions to figure out how to parse
its cookie and/or how to get data out of its backing store, and you
don't think that relying on its implementation details in this way is a
problem, but reading its code to figure out where it stashes the session
id is infuriating?
I don't see why you consider it more acceptable to force this on users
than to just modify the existing ISession implementations in one
swoop. There are only two of them I'm aware of, 'pyramid_beaker' and
'pyramid_redis_sessions'. 'pyramid_beaker' already has 'session.id',
so it's just a matter of getting it into 'pyramid_redis_sessions'.
Which already has the ID, it just needs to put it on 'session.id'. The
implementations in Pyramid would all use the dummy alternative (i.e.,
None) since they don't have IDs. So 1, 2, 3 and it's done. The hardest
part is 'pyramid_redis_sessions', but that would be easier for the
maintainer who knows the code to do than for a user to do (because I
tried and failed).
I say this because,
presuming we did mandate that, you'd still have a heck of a lot of work to
do if you wanted to switch sessioning implementations in midstream to make
those tests pass and features work.
I wouldn't expect existing sessions to remain valid when switching
backends. I'd clear them all out.
I'm not talking about session data. I'm talking about code that
Jonathan wrote to verify that indeed session info was *put into redis*.
That was the case he gave. If he switched sessioning implementations,
he's going to need to change that code. Likewise, if he goes behind the
back of ISession to "cross-load session data" as he described, he's
going to need to change not just test code, but runtime code too.
I already wrote details of a scenario where a None (optional) session id is
suboptimal in a prior email in this thread.
It's a theoretical use case, like this three-independent-person
scenario you're insisting in. Whereas Jonathan and I have concrete
existing cases.
You do indeed have concrete existing use cases, but they aren't
satisfied by just adding a session.id, AFAICT.
session id uniformly is actually correct. That doesn't mean that session
implementations can't expose it; pyramid_redis_session sessions already
expose the session id (as session.session_id, FWIW),
No it doesn't. That's how I lost a month's worth of session counts
when I switched from 'pyramid_beaker' to 'pyramid_redis_sessions'.
I'm not sure how to interpret this, then:
<https://github.com/ericrasmussen/pyramid_redis_sessions/blob/master/pyramid_redis_sessions/session.py#L74>
- C
--
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 pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
