-> >On 5/18/05, Titus Brown <[EMAIL PROTECTED]> wrote:
-> ><good arguments to remove the dictionary interface from SessionManager>
-> >
-> >I wonder if we can also remove is_dirty. The code says:
-> >
-> > elif session.is_dirty():
-> > # We have already stored this session, but it's dirty
-> > # and needs to be stored again. This will never happen
-> > # with the default Session class, but it's there for
-> > # applications using a persistence mechanism that requires
-> > # repeatedly storing the same object in the same mapping.
-> > self[session.id] = session
-> >
-> >so if I use shelve with "writeback=True" or Zope "PersistentDict" and I
-> >commit the change at the end of the request I don't need it, right? I
-> >found
-> >is_dirty to be one of the most confusing things in the persistency
-> >mechanism,
-> >since it feels like a hack to accomodate the simplest usage of shelve and
-> >the ZODB.
->
-> I have twice tried to make a DBAPI_SessionManager, most recently two
-> days ago in consultation with Titus, and I keep giving up because it's
-> so confusing. It seems so simple in concept: sessions have a string ID
-> and a pickled body, just like a dictionary. Unfreeze the session at the
-> beginning, freeze it at the end. But then there's this transaction
-> complication, ._set_access_time (in which Titus sets ._dirty to True,
-> and I'm trying to verify whether it's called in exactly the appropriate
-> circumstances), .is_dirty (I've never figured out how to set this
-> properly so I just let it follow .has_info), access_time which must be
-> saved, and create_time which I don't see the need for but I suppose must
-> be saved too. My database (MySQL) isn't transaction safe anyway, so I'd
-> just be including the transaction code as an extra. But tracing through
-> when the various code is called and comparing it to what should be
-> called is difficult because there's no spec to compare it to. "Various
-> code" meaning writing to the session, setting the access time (at
-> unfreeze? at every write? at freeze?), saving the session, and then
-> commit or rollback as a separate step.
Hmm, I thought I understood the use of is_dirty(), but now I'm getting
confused too ;).
In Quixote, the decision on whether or not the session is to be saved
belongs to SessionManager. The relevant decision tree is this:
---
if not session.has_info():
if session.id:
delete_session()
return
if session.has_info() and session.id is None:
create_session_id()
save_session()
return
if session.has_info() and session.is_dirty():
save_session()
return
# remaining:
if session.has_info() and not session.is_dirty():
return
### never get here <--
---
If you add in transactions, then this code only has effect when
finish_successful_request() is called, and it should have no effect
when finish_failed_request() is called.
You don't need is_dirty() if, after the first save_session(), any
changes to the session are automatically saved. I believe this
happens with Durus and ZODB, and can be mimicked very easily
with an SQL database adapter.
You don't need is_dirty() if your session doesn't change, because
it never needs to be saved again.
You *do* need is_dirty() if your Session object isn't linked to the
database by itself and it needs to be re-saved whenever a successful
request happens. (This is how my code generally works.)
Does this make things any clearer? ;)
--titus
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
