[BlueBream] [Zope-dev] Reg. persisting data in ZODB via forms

[Laurence Rowe]

On 8 June 2011 10:05, Joe Steeve <js at hipro.co.in> wrote:
> Hello Charlie,
>
> On Wed, 2011-06-08 at 10:48 +0200, Charlie Clark wrote:
>> From memory I can recall something similar related to making changes
>> to copies of instance attributes but failing to apply them to
>> attributes and needing to specifically go context.attribute =
>> form_result for the changes to persist.
>
> Supposing, we have a form action like:
>
>        @form.action('Apply')
>        def handle_edit(self, action, data):
>                self.context.name += "Blah"
>
> This change is visible in subsequent requests. i.e if we view this
> object via another form, we can see the modification. However, if we
> restart the server (bluebream), this change is lost. The same thing
> happens when we use "form.applyData". If we 'notify'
> ObjectModifiedEvent, this does not happen.
>
> Since the object's modification is visible across requests, I am
> assuming that the transaction mechanism 'did' apply the changes to the
> object.
>
> But, it did not get to the disk :-/

This looks like self.context is not an instance of a Persistent
subclass. Only Persistent subclasses know how to register their
changes with the ZODB. You see the change on subsequent requests
because the object remains in the object cache, as soon as it's parent
Persistent instance is invalidated, or the server restarted the
changes will disappear. Storing mutable non-persistent objects in the
ZODB requires some care, specifically you need to register the change
on the object's persistent parent. The easiest way to do this is to
assign it to the parent again, e.g. parent['child-name'] = child.

My guess is that the ObjectModifiedEvent is dispatched to your
object's parent and causes something to change there, with the side
effect of storing your updated object.

Laurence