On Fri, 20 Feb 2004 10:53:30 -0500 Casey Duncan <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Feb 2004 09:47:47 +1100 > Richard Jones <[EMAIL PROTECTED]> 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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
