[Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts

[Dennis Allison]

The interaction between sessions, conflicts, and persistence is a bit
confusing.  I am still trying to understand the code in depth.  

One thing is for sure, request.SESSION and/or request['SESSION'] must be
persistent for things to work.  Mutable objects in the session variable
set (dictionaries and lists) have to be handled specially to get the
persistence machinery to recognize they have been changed.

In this case, I am trying to ensure that the session variables get 
identified as persistent.  My question is whether using update (an 
implicit assignment) triggers the persistence mechanism.  It is the 
moral equivalent of writing 

	request['SESSION']['alpha'] = 'a'B
	request['SESSION']['beta'] = 'b'

but I am unsure whether the persistence mechanism will recognize it as 
such.  

Doing session variable initialization in a Script(Python) object has a
downside because one cannot set a _p_changed attribute and so must rely on
the assignment paradigm.  Perhaps the interface should be in a Product or
External Method which is less constrained.

Anyhow, David, thanks for the assist.


On Mon, 19 Dec 2005, David H wrote:

> Dennis Allison wrote:
> 
> >Chris McDonough identified a persistence problem with the routine(s) that 
> >manage sessions variables.  (Thanks Chris)  I have put the correction in 
> >place which resolved some (but not all) of the problems.
> >
> >There are still problems which are apparently due conflicts in accessing
> >the session variables.  To minimize frequency of conflicts, I am rewriting
> >several routines using Dieter's rules of the thumb (Thanks Dieter).
> >
> >One routine being modified is a Script(Python) that initializes a number
> >of session variables.  I am collecting the session values in a dictionary
> >and then use update to set their value, for example:
> >
> >	s = {}
> >	s['alpha'] = 'a'
> >	s['beta'] = 'b'
> >	request['SESSION'].update(s)
> >
> >Is the persistence machinery smart enough to detect this as a change?  I
> >suspect that it has to be flagged since the assignment won't be seen.  
> >Usually this means setting the _p_changed=1 attribute, but it is not clear
> >to me where to set it in this particular context.  
> >

> Dennis,
> 
> Did you means request['SESSION']['someDictionary'].update(s)?
> Anyway your idea seems correct - The SESSIONS chapter (at least on 
> plope.com) addresses SESSION "staleness" and mutable objects.
> 
> 1) someDict = SESSION['someDict']
> 2) someDict['someKey'] = "newValue"
> 
> But (2) does not guarentee that a subsequent lookups like:
> SESSION['someDict'] will return "newValue".
> 
> But this WILL:
> 3) SESSION['someDict'] = someDict.
> 
> Which looks like your example.  How this connect to your primary issue:  
> *conflicts* is not clear to me.  :-\
> 
> David
> 
> 

--