> - 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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
