Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-06-03 Thread Dieter Maurer
Raphael Ritz wrote at 2005-6-3 09:40 +0200: >Chris Withers wrote: >[..] >> That said, I'm also aware that there are currently 4 of us talking about >> this, 2 on each side. What does the rest of the community think? >> > >Since you ask so explicitly ;-) > >I agree with Florent: Your site's _USERES

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-06-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Raphael Ritz wrote: > >> Since you ask so explicitly ;-) >> >> I agree with Florent: Your site's _USERES_ should never get >> an error thrown at. > > > Even if they're potentially destroying their own data as a result?! Chris

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-06-03 Thread Chris Withers
Raphael Ritz wrote: Since you ask so explicitly ;-) I agree with Florent: Your site's _USERES_ should never get an error thrown at. Even if they're potentially destroying their own data as a result?! Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.s

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-06-03 Thread Raphael Ritz
Chris Withers wrote: [..] That said, I'm also aware that there are currently 4 of us talking about this, 2 on each side. What does the rest of the community think? Since you ask so explicitly ;-) I agree with Florent: Your site's _USERES_ should never get an error thrown at. There are other w

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-06-02 Thread Chris Withers
Tres Seaver wrote: Exactly. The point is that the "adverse effect" *already happened*, in some prior request, probably due to one of Chris' beloved hasattrs ;). The current request should *not* be prevented from continuing. Why not? Chris, take this as a fiat: this one will *never* turn int

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-05-27 Thread Dieter Maurer
Florent Guillaume wrote at 2005-5-27 13:30 +0200: > ... >Let's not go into too much semantics here. Note that WARNING is an alias >of PROBLEM. zLOG defines these levels as: > > PROBLEM=100 -- This isn't causing any immediate problems, but deserves > attention. > > ERROR=200-

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-05-27 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > Dieter Maurer <[EMAIL PROTECTED]> wrote: > [about getObject logging missing objects] > >>>Yes, logging should be there. I'll add a LOG at level WARNING somewhere, >>>I'm not sure where (after all it's unrestrictedTraverse t

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-05-27 Thread Florent Guillaume
Dieter Maurer <[EMAIL PROTECTED]> wrote: [about getObject logging missing objects] > >Yes, logging should be there. I'll add a LOG at level WARNING somewhere, > >I'm not sure where (after all it's unrestrictedTraverse that does the > >catching). > > When something in the catalog tells you, there

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-05-26 Thread Chris Withers
Dieter Maurer wrote: Yes, logging should be there. I'll add a LOG at level WARNING somewhere, I'm not sure where (after all it's unrestrictedTraverse that does the catching). When something in the catalog tells you, there were an object and the object is not locatable, then this is an ERROR an

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-05-03 Thread Dieter Maurer
Florent Guillaume wrote at 2005-4-22 17:17 +0200: >Chris Withers <[EMAIL PROTECTED]> wrote: > ... >> Yes we do! I really really really want to know if: >> - I have a catalog entry that points to an object that no longer exists. >> This can ONLY happen due to a bug somewhere and needs to be fixed

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-04-22 Thread Florent Guillaume
Chris Withers <[EMAIL PROTECTED]> wrote: > > The None issue is a red herring, it's just that we *don't* want to fail > > even if there are broken indexes. No we don't. We're reindexing what we > > can find in the catalog. We don't want an exception. > > Yes we do! I really really really want to k

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-04-21 Thread Chris Withers
Florent Guillaume wrote: Please read and understand the code more carefully. There is no expected error. reindexObjectSecurity (which I introduced more than 2 years ago because CMF was buggy without it) needs access to all subobjects to reindex them. To do that it has to: 1. use an unrestricted se

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-04-20 Thread Florent Guillaume
Chris Withers <[EMAIL PROTECTED]> wrote: > Tres Seaver wrote: > > > Chris, you need to get off this hobby horse. Florent's fix was correct > > for the *new* model which has 'getObject' raising (a model you profess > > to *like*). > > Why not by catching the expected errors? Do you like bare try

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-04-20 Thread Chris Withers
Tres Seaver wrote: Chris, you need to get off this hobby horse. Florent's fix was correct for the *new* model which has 'getObject' raising (a model you profess to *like*). Why not by catching the expected errors? Do you like bare try: except:'s? (since that's effectively what this is!) Bugs in

[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

2005-04-20 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Florent Guillaume wrote: > Specifically, in CMFCatalogAware.reindexObjectSecurity (recently introduced by Florent Guillaume if I recall), it assumes getObject() will return None in a failure. >>> >>> >>> Yes, see