Fw: [Zope-dev] Storing session objects in a ZODB
This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously. Input welcomed! - C ----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace.
Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state.
Bingo, yes that's it!
Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it?
Absolutely!
-- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Andy McKay" <andym@ActiveState.com> Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB
Andy,
I'm still not sure why you wouldn't set up an external data
container..
if
you want, you can call me at 540-371-6909 if you think you can explain it better over the phone...
- C
----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Tuesday, January 30, 2001 12:28 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
Well each user rummages through a site and saves preferences, I use these preferences for displaying things in a certain manner, generating SQL etc. Since some of these SQL statements get quite complex, it would be nice to be to able to pull saved session x which has a query that "looks up by x by y excluding z" etc...
So anyway I like using the ZODB for this kind of storage since it's of low volume and a large amount of reads and the users want to use acquisition to the full (we have a wacky hierarchy). If I could pull that into a text area to allow level editing then that would be an added bonus...
Did that make sense? -- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Andy McKay" <andym@ActiveState.com> Sent: Monday, January 29, 2001 5:49 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
> Sure but users want to be able acess and manipulate the stored session > objects, without them being loaded... Im going for a bike ride to think > about this one.
Erm. What? :-) Can you give me an example?
Well my quick hack and wacky of doing it is as follows: - I wrote a quick simple class "ZStore" that has as one of its properties a pickle, which you can read and write to using cStringIO - I make a ZStore object, throw in the session object, it pickles it as the data property, I add a few more useful properties, like title, owner etc... - To get it back I get that object, unpickle that property and I have the session back. Quick hack that works for me and allows me to change the content of a session object, without having to change the storage. Im sure someone will come up with a better solution. -- Andy McKay. ----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: <zope-dev@zope.org> Sent: Wednesday, January 31, 2001 11:28 AM Subject: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously.
Input welcomed!
- C
----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace.
Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state.
Bingo, yes that's it!
Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it?
Absolutely!
-- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Andy McKay" <andym@ActiveState.com> Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB
Andy,
I'm still not sure why you wouldn't set up an external data
container..
if
you want, you can call me at 540-371-6909 if you think you can explain it better over the phone...
- C
----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Tuesday, January 30, 2001 12:28 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
Well each user rummages through a site and saves preferences, I use these preferences for displaying things in a certain manner, generating SQL etc. Since some of these SQL statements get quite complex, it would be nice to be to able to pull saved session x which has a query that "looks up by x by y excluding z" etc...
So anyway I like using the ZODB for this kind of storage since it's of low volume and a large amount of reads and the users want to use acquisition to the full (we have a wacky hierarchy). If I could pull that into a text area to allow level editing then that would be an added bonus...
Did that make sense? -- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Andy McKay" <andym@ActiveState.com> Sent: Monday, January 29, 2001 5:49 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
> > Sure but users want to be able acess and manipulate the stored session > > objects, without them being loaded... Im going for a bike ride to think > > about this one. > > Erm. What? :-) Can you give me an example? > >
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Cool! Note that the session data object implements the mapping interface, so you don't really need to pickle up a copy of it. I'd recommend against this, although it seems to be working well for you. Instead, to save a session state, I'd just grab the current session data object and iterate over its items, grabbing things out of it that are interesting to my application. Then I'd copy these things into another data structure, maybe by sticking them into an instance of a class that also implements the mapping interface and put that instance in a folder somewhere which is related to the currently logged-in user. Then when a user wanted to restore a saved session state, get a list of session state objects in his session state folder, present them to him, have him select one. When he does, copy the items out of it into the current session data object. The nice thing about this general strategy is that you can work with the current session data object in all of your app code that depends on session state. How the session state is saved and restored (and what the session data object values are) is completely independent of the app code. ----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com>; <zope-dev@zope.org> Sent: Wednesday, January 31, 2001 2:47 PM Subject: Re: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
Well my quick hack and wacky of doing it is as follows:
- I wrote a quick simple class "ZStore" that has as one of its properties a pickle, which you can read and write to using cStringIO - I make a ZStore object, throw in the session object, it pickles it as the data property, I add a few more useful properties, like title, owner etc... - To get it back I get that object, unpickle that property and I have the session back.
Quick hack that works for me and allows me to change the content of a session object, without having to change the storage. Im sure someone will come up with a better solution.
-- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: <zope-dev@zope.org> Sent: Wednesday, January 31, 2001 11:28 AM Subject: [Zope-dev] Fw: [Zope-dev] Storing session objects in a ZODB
This is a forwarding of an interesting session-related discussion between Andy and I... it covers the idea of storing session states as "snapshots" at a particular time, later allowing users to select a session state. This is useful if you wish to allow users to make incremental changes to data in a session and "bookmark" a session state for later copying into the current session. This is something that the "bare" session tracking stuff won't do for you, although it can facilitate it tremendously.
Input welcomed!
- C
----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Wednesday, January 31, 2001 1:56 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
I think you may be trying to use sessions to do something that sessions don't do. You can *use* the sessioning machinery as a base to build the infrastructure to do such a thing, but it won't do it out of the box. I am currently trying to build an "onSessionStart" and "onSessionEnd" event into session data objects. If you had this capability, an arbitrary Python method (or DTML method or external method) could be called when a session data object is created and when it expires. If you were to make use of these hooks to copy the state of the session data object into another structure (related to the currently logged in user - a "checkpoint" if you will), you could build a catalog of session states that could be recopied into the current session namespace.
Alternately, you could forego the use of events and just have a button that says "save session state" somewhere, and copy the contents of the session namespace into something else. Then when a user wanted to choose a session state, copy it back into the current session namespace. This is the same idea, it just lets the user be explicit about what session state he wants to use instead of depending on the event hook to create a new state.
Bingo, yes that's it!
Does this make sense? Can I cc this to Zope-Dev so we can get some discussion about it?
Absolutely!
-- Andy McKay.
----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Andy McKay" <andym@ActiveState.com> Sent: Tuesday, January 30, 2001 9:53 AM Subject: Re: [Zope-dev] Storing session objects in a ZODB
Andy,
I'm still not sure why you wouldn't set up an external data
container..
if
you want, you can call me at 540-371-6909 if you think you can explain it better over the phone...
- C
----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: "Chris McDonough" <chrism@digicool.com> Sent: Tuesday, January 30, 2001 12:28 PM Subject: Re: [Zope-dev] Storing session objects in a ZODB
> Well each user rummages through a site and saves preferences, I use these > preferences for displaying things in a certain manner, generating SQL etc. > Since some of these SQL statements get quite complex, it would be nice to be > to able to pull saved session x which has a query that "looks up by x by y > excluding z" etc... > > So anyway I like using the ZODB for this kind of storage since it's of low > volume and a large amount of reads and the users want to use acquisition to > the full (we have a wacky hierarchy). If I could pull that into a text area > to allow level editing then that would be an added bonus... > > Did that make sense? > -- > Andy McKay. > > > ----- Original Message ----- > From: "Chris McDonough" <chrism@digicool.com> > To: "Andy McKay" <andym@ActiveState.com> > Sent: Monday, January 29, 2001 5:49 PM > Subject: Re: [Zope-dev] Storing session objects in a ZODB > > > > > Sure but users want to be able acess and manipulate the stored session > > > objects, without them being loaded... Im going for a bike ride to think > > > about this one. > > > > Erm. What? :-) Can you give me an example? > > > > > >
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Cool! Note that the session data object implements the mapping interface, so you don't really need to pickle up a copy of it. I'd recommend against this, although it seems to be working well for you.
Any special reason why I shouldn't pickle apart from the fact that the ZODB will do it to save the object?
Instead, to save a session state, I'd just grab the current session data object and iterate over its items, grabbing things out of it that are interesting to my application. Then I'd copy these things into another data structure, maybe by sticking them into an instance of a class that also implements the mapping interface and put that instance in a folder somewhere which is related to the currently logged-in user.
Cool, I'll have to look at the mapping interface. I use a "fixed" version of UserInfoFolder to maintain a folderish object on each person, Im throwing this into there. Works nicely.
Then when a user wanted to restore a saved session state, get a list of session state objects in his session state folder, present them to him, have him select one. When he does, copy the items out of it into the current session data object.
The nice thing about this general strategy is that you can work with the current session data object in all of your app code that depends on session state. How the session state is saved and restored (and what the session data object values are) is completely independent of the app code.
Yep this is what I like. Im actually thinking this simple ZStore class is a useful little object for throwing stuff into, if I get mapping working I'll release the whole 50 lines of code it currently is... Thanks for your help. -- Andy McKay.
Any special reason why I shouldn't pickle apart from the fact that the ZODB will do it to save the object?
The session data object class may move in the future, which in the "normal" case would only require that you restart the server (if they're transient) or flush your data container (if they're persistent). But if you've got pickles of older session data objects hanging around (which point to a no-longer-existing class), your app will likely break. Instead, it's better to rely on a class that you have some control over. Using pickles of session data objects, you're depending on an implementation detail that may change. Additionally, I doubt it's the case in your implementation, but unpickling arbitrary user-contributed data can be a serious security hole. In broader terms, however, you already have a superpickler (the ZODB), you might as well use it. ;-) When I say mapping interface, I just mean that the session data object looks like a dictionary. So: mystorageobject = mycustomclassthatlookslikeadictionary() data = sdm.getSessionData() for k,v in data.items(): mystorageobject[k] = v afolder._setObject('anid', mystorageobject) Will do the right thing.
Yep this is what I like. Im actually thinking this simple ZStore class is a useful little object for throwing stuff into, if I get mapping working I'll release the whole 50 lines of code it currently is...
It would be really useful to have generalized support for something like this.
In broader terms, however, you already have a superpickler (the ZODB), you might as well use it. ;-)
Oh I agree entirely...
When I say mapping interface, I just mean that the session data object looks like a dictionary. So:
mystorageobject = mycustomclassthatlookslikeadictionary() data = sdm.getSessionData() for k,v in data.items(): mystorageobject[k] = v afolder._setObject('anid', mystorageobject)
Will do the right thing.
Ah that's too easy. This is a useful little class actually, it maps the session objects properties to class properties etc then reads them back out again. Pickling seemed much easier but I agree with the reasons not to... Thanks works like a charm now... Cheers.
participants (2)
-
Andy McKay -
Chris McDonough