Tres - I am 98% sure I found the source of my problem.  I thought I
was getting a copy of something back, when really I was getting a
pointer to it.  So I was changing the catalog.   I am still slightly
confused as to how it fixed itself (probably was due to data being

In my code I have -
           reqAccesses = results[index].getAccess

       for access in usrAccesses :
           if access in reqAccesses :

I am getting a reference though, so when I do remove() I am changing
the actual catalog values.

It looks like it is fixed by doing
reqAccesses = results[index].getAccess.copy()

I would like to thank you though for helping me deal with my
stupidity.  This one was really stumping me since it seemed as though
my code wasn't always involved.

On 3/7/08, Ryan Smith <[EMAIL PROTECTED]> wrote:
> >
> > My output was using a KeywordIndex, with 'and' as the operator.
> >
> > I noted when reading your earlier description that your code was testing
> > the value of the 'getAccess' entry in the *metadata*, not in the index:
> > in fact, you don't need an index at all to do the filtering in that
> > code. Can you check on the "Catalog" tab that the metadata for your
> > indexed objects has the correct 'getAccess' values?
> >
> To answer your question.  For something lets say fileab (which should
> have 'alpha' and 'beta'):
> If the index is correct: I went to catalog, then clicked fileab, then
> checked the getAccess key and it was correct, ['alpha', 'beta', ''].
> If the index is wrong: Doing the same the the getAccess key is wrong,
> ['beta'].
> -----------------------------------
> I realized something this morning.  The bug is only reproducable, if
> there are concurrent connections.  Someone else mentioned that
> concurrent connections resulted in wrong catalog entries.  At first I
> thought this wasn't always the case for me, but it is.
> If I log in as an admin and I continuously refresh the catalog, it
> looks like it will always be correct.
> If, though, I open a second browser and log in as a normal user, I am
> able to cause the problem to happen fairly often by updating the
> catalog.
> - Ryan

Ryan Smith
859-338-4713 (c)
Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to