[Zope-dev] Re: Temporary Storage + Sessions + Versions: How?

[Chris McDonough]

> - I have an index_html method that calls an "initializeSession" method at
> the beginning to initialize certain session variables. (Is there another
way
> to do this?)

Yes, you can use an "script to call when objects are added" method in the
transient data container related to the session in order to establish
default values.

> - As the new sessioning code seems to be working within the transaction
> machinery, the SESSION.set action causes the mere display of an index_html
> page (that includes a session initialization method) to be added to the
undo
> logs

The start of a session or changes to the session namespace cause writes to
the database in which the data container related to the session is stored.
This is the essence of how the sessioning stuff works.

> Strictly speaking, this behaviour might be correct, as the SESSION.set
> indeed changes stuff. But it just isn't usable like that. How am I
supposed
> to use sessions together with versioning at all if I can't even temporarly
> set session keys without getting them committed in a transaction?

I suspect you're the first person to connect this phenomea with sessions,
but it has precedent (see below).

> I think that sessions have to act like a temporary, volatile namespace,
> something like the REQUEST namespace, but persistent for the time of the
> session.

This is what they are, you've just run in to a limitation of sessions in
conjunction with versions.

Was your data container stored in the "main" database?  It sounds like it
was, but you didn't say.

> Chris, in your first response you said that there might be usage
> patterns where people want sessions to be version-aware (or let's put it
> more general: transaction-aware). But I think that is not quite true: If I
> want something like that, I can use plain properties and store them in an
> object.

I dont think I understand.  Can you explain more?

> Finally, let me state what I think is a fact: As of Zope 2.5 b3, you can
> either use versions OR sessions. If you try to combine them, you'll get
into
> big trouble. This is a major bug, right?

This depends on your definition of major. FWIW, the same problem happens
with methods that Catalog writes in conjunction with versions.  You get
items "stuck" with a version lock error outside of the version -- objects
that you didn't "expect" to be locked.

Versions are pretty evil in some ways, this being one.  What you're
encountering is arguably more a bug in versions that a bug in sessions.
Someone operating in a version believes that they are not effecting the site
in any way whatsoever, and this is just not true -- what they do impacts the
site greatly.  Versions are very enticing and mostly a lie. ;-)

That said, I agree that versions w/ sessions are a "gotcha" waiting to
happen, although I wouldn't agree that it's a bug.  Short of rewriting the
version code, I think maybe writing a storage that "pretended" to be in a
version instead of actually being in one is probably the right answer.  This
could be a modification to TemporaryStorage or it could be an entirely new
storage.  However, I think we'd need to consider what the flip side of this
carefully.  I wouldn't want to err on the side of "magic" in this way
without considering the impact.

- C