[Zope-dev] Re: "hasattr" geddon

[Shane Hathaway]

On Saturday 10 July 2004 20:54 pm, Casey Duncan wrote:
> Shane Hathaway <shane at hathawaymix.org> wrote:
> > Why are
> > we fixing hasattr and bare excepts when the real problem is ZODB?
>
> Well, the real problem is *probably* people, but I digress...

http://c2.com/cgi/wiki?TheProcessIsTheProblem ;-)

> Still, swallowing read conflicts can lead to bugs, even in read-only
> tranactions. Consider the following function:
>
> def getStuffFrom(ob, default):
>     if hasattr(ob, 'stuff'):
>         return ob.stuff
>     return default
>
> I have seen this idiom about in some zope application/framework code. If
> the hasattr results in a read conflict, then it returns false and
> default is returned by the function even if ob does have the attribute.
> In the example I saw (in DCWorkflow) this would result in the wrong UI
> elements being displayed for ob mysteriously. Reloading the page would
> likely fix the problem, baffling both the user and app developer, who
> now both think Zope is playing with their minds.

The change to ZODB that I'm suggesting would fix this.  The suppressed 
conflict error would still mark the transaction as uncommitable.  When the 
publisher calls commit() (which it does on every request even if nothing 
changed), it would result in a ConflictError, then the publisher would call 
abort() and the transaction would be retried.  Users would never see results 
from a transaction that had any conflict.

Shane