On Wed, 09 Mar 2005 17:12:43 -0500, Chris Kratz wrote:
On Wednesday 09 March 2005 05:09 pm, Chris McDonough wrote:
Yup, this is a common issue that bites many people when they do ZODB programming. For better or worse, we've made the scripter into a ZODB programmer via offering sessions.
The sad thing is that I knew this to be the case with standard ZODB programming. Hence the huch. What I didn't realize is that the SESSION code worked the same way for some reason.
Oh well, thanks again.
While we're on the topic of the one downside of making Session objects ZODB objects like any other, I thought I'd jump in and point out the advantage. I've worked with other systems where sessions are just a standard in-memory object, and this is a much nicer approach. Since sessions are ZODB objects, you can switch to store your sessions in a database, or in memory on a ZEO server, just by playing with your configuration. All the usual ZODB mechanisms for transaction handling and changed-object invalidation come into play for free, giving you a distributed and/or fully persistent session store which is much easier to use and set up than most, and with far fewer limitations on the structure of your session data. Thanks, Malcolm. -- [] j a m k i t web solutions for charities malcolm cleaton T: 020 7549 0520 F: 020 7490 1152 M: 07986 563852 W: www.jamkit.com