[Zope-CMF] Re: Delete trouble

Dieter Maurer dieter at handshake.de
Thu Mar 29 16:30:47 EDT 2007


Philipp von Weitershausen wrote at 2007-3-28 08:16 +0200:
> ...
>What makes you think you can make that assumption? This is Zope 2 all  
>over again, where things just have to be there. That won't help  
>making things more flexible.

Hiding exceptions (or avoiding them at all costs) might be seen as
more flexible -- but this approach caused several quality problems in
Zope 2.

>> We have this situation here: there should be (and is) a unique
>> id tool but the local registrations have not been performed.
>
>Nope, we're just not operating in a place where we can get to the  
>tool. It's standard acquisition semantics.

With standard acquisition semantics, you get an AttributeError
when the object is not there.

You propose something similar (okay, a bit less drastic) to
silently ignoring the "AttributeError".

I argue that (in general, there are exceptions) we should get the exception.

>
>> An exception is better than silently omit the update of the existing
>> unique id tool.
>> You could argue that the local id tool does not need to be updated
>> as the complete site (including the tool) gets deleted.
>
>Indeed.
>
>> But would the effect be different, if I used:
>>
>>     plone_site.some_folder.manage_deleteObjects(....).
>>
>> Or in other words, is attribute lookup entailed in traversal?
>
>No.
>
>> If it is not (which I assume), then your "defensive programming"
>> would hide inconsistencies in the unique id tool -- similar
>> to a "defensive try: .... except: pass".
>
>What kind of inconsistencies? We're deleting the thing anyway, what's  
>the point to update it?

If you carefully look at the example, it no longer deletes "plone_side"
(and its "unique id tool") but something below "plone_side".
Therefore, consistency of the "unique_id_tool" may be an issue (it is
not deleted and would know about an object with no longer exists).



-- 
Dieter


More information about the Zope-CMF mailing list