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.
> 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.
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 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.
> 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'.
--
Mike Orr <sluggos...@gmail.com>
--
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.
