On Dec 20, 2005, at 12:36 AM, Dennis Allison wrote:
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.
Trimmed Zope-dev from this (cross-posts are bad)...
Dennis,
Lets just put the question out there: Does:
SESSION['someKey'] = someValue
Force a commited transaction?
As opposed to ...
someDict = Session['SomeKey']
someDict['aKey'] = 'aNewValue'
Neither forces a committed transaction, but
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
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
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
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
Dennis Allison wrote:
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
