> Any special reason why I shouldn't pickle apart from the fact that the
> 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
Will do the right thing.
> Yep this is what I like. Im actually thinking this simple ZStore class is
> useful little object for throwing stuff into, if I get mapping working
> release the whole 50 lines of code it currently is...
It would be really useful to have generalized support for something like
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -