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.