>>Hello, I've got some problems using the FileSessionStore or the =
>>Store when there are any MiddleObjects stored in the session. I'm =
>>MiddleKit and PostgreSQL. The SessionStore isn't able to store a=20
>>MiddleObject with a reference to _mk_store (with database =
>>hope, I solved the problem by adding __getstate__ and __setstate__ to =
>> odict =3D self.__dict__.copy()
>> del odict['_mk_store']
>> return odict
>> self.__dict__ =3D dict
>> self.__dict__['_mk_store'] =3D MiddleKit.Run.ObjectStore.Store
>>It works. But is it save?
>The first thing that bothers me is that there could be changes to the=20
>object in the store's memory and even the database, that would not be=20
>reflected in the pickled session. For that reason, I would say "No, =
>MiddleObjects in a pickled file is not 'safe', or at least not a good
>But I think there is still an approach that would give you what you =
>The essence is to pickle a reference to the middle object.
>* The "hard work approach" would be to store the class name and serial =
>number of the object in the session. You can then use =
>You might even be able to use the object's key (which is just the =
>class name and serial num), although I haven't tested this yet:
> sess =3D self.session()
> sess['cartKey'] =3D cart.key() # store the object
> cart =3D store.object(sess['cartKey']) # retrieve the object
>The problem is that using session in that way wouldn't be as natural.
>* Augment the Session by providing a __getstate__ and __savestate_ =
>does what I just described. You could code it for particular keys =
>taken from an attribute), or better yet, albeit more expensive, check =
>instances of MiddleObject.
>I strongly suggest switching techniques and I think the above approach =
>work out. Please let us know what you end up doing.
I do certainly agree but still have some problems concerning my =
reasons for storing middle objects in a session. I want to store those
objects temporary before a change of those objects get reflected in the
and even in the store. A user should be able to fetch an object out of =
store (or, alternatively, build a new object from the scratch), then to
it in various (!) stages without reflecting the original object in the
or in the store. Only if the user submits the changes, the changes in =
temporary object will be reflected in the store.