[ZODB-Dev] How to check for setting the same values on persistent objects?

[Hanno Schlichting]

On Fri, May 6, 2011 at 3:50 PM, Jim Fulton <jim at zope.com> wrote:
>> 1. Encourage everyone to do the old == new check in all application
>> code before setting attributes on persistent objects.
>
> -1 at suggested, but it might be worth asking if there should be
> changes to infrastructure that encourages lots of spurious attribute
> updates.

Ok. I guess if ZODB documentation ever becomes available, it would be
at least good to point this out clearly.

>From what I found so far, the spurious changes come from "edit forms"
that display a lot of values coming from different persistent objects
and then unconditionally do a setattr with the values coming from the
request again. I guess you could argue the "hasn't changed" check
should be performed by the forms / widget layer here.

>> 2. Create new persistent base classes which do the checking in their
>> __setattr__ methods
>
> -1.  This feels like adding a solution to some other solution. :)

Right. But it's apparently been popular enough to get implemented in
lovely.persistent at
http://svn.zope.org/lovely.persistent/trunk/src/lovely/persistent/app.py?rev=82239&view=markup

So I think it's not completely unwarranted to bring this topic up.

>> 3. Compare object state at the level of the pickled binary data
>
> There are also possible subtle consistency issues.  If an application
> assigns the same value to a variable and some other transaction
> assigns a different value, should the 2 conflict? Arguably so.

Wouldn't it be enough to mark the object via readCurrent for this case?

>> Maybe option one is the easiest here, but it would need some
>> documentation about this being a best practice. Until now I didn't
>> realize the implications of setting attributes to unchanged values.
>
> I think the best approach is to revisit the application infrastructure that's
> causing all these spurious updates.

I'll keep doing that. It just strikes me that this has happened in so
many places in the Plone code and nobody noticed it so far. If the
Plone folks are the only ones making this mistake, it's our job to fix
it. If it's a common mistake done by other projects, there might be
something to it.

Hanno