[Zope-dev] Re: Zope 2.7 and objects turning into None

[Casey Duncan]

On Fri, 20 Feb 2004 10:53:30 -0500
Casey Duncan <casey at zope.com> wrote:

> On Fri, 20 Feb 2004 09:47:47 +1100
> Richard Jones <richardjones at optushome.com.au> wrote:
> 
> > On Friday 20 February 2004 05:52, Dieter Maurer wrote:
> > > We have a report for Zope 2.7 about an object magically turning
> > > into "None" (1 or 2 weeks ago).
> > 
> > Sorry, I haven't been following this thread, but I will note that
> > I've seen (repeatably) in my test Zope environment this behaviour.
> > 
> > This is probably unrelated though...
> > 
> > For me, the situation comes about when I am loading up my fresh (ie.
> > clean ZODB) test Zope with a thousand users. While the load script
> > is running (it runs on the command-line and goes TTW using urllib to
> > register the users) if I access a page which summarises all users, I
> > *sometimes* get None for some of the users. The page uses a Catalog
> > to find basic user info, and sometimes uses getObject() to find the
> > real user object. The getObject() appears to return None sometimes.
> 
> This is a guess, but perhaps the Catalog is masking some other
> low-level error and returning None instead? I'll see if that seems
> possible from the code.

This is indeed possible. getObject swallows all errors and returns None
when one occurs. This would make it return None on busy systems if the
traversal during getObject raised a read ConflictError.

I consider this a bug and I will look into what the *real* desired
semantics are. I've been bitten myself by this in applications which
naively assumed getObject would always return a Zope object.

It might be sane to return None in the case where a cataloged object has
been deleted and not uncataloged. For Zope 2.7 at least we should
probably preserve these semantics.

I propose however that if an unusual exception (ConflictError,
MemoryError, SystemExit ;^) occurs, it should be propagated to the
client, since it indicates a true exceptional condition. ConflictError
propagation especially would help not miss results since it would force
a retry of the transaction. This is crucial to applications which rely
on catalog results to access objects which require action (I'm thinking
specifically of the reindexObjectSecurity method in CMFCatalogAware).

For Zope 2.8 it might be reasonable to consider also making the case
where accessing objects that have been removed without uncataloging is
also an exception. 

What do people think?

-Casey