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 cached).
In my code I have - reqAccesses = results[index].getAccess for access in usrAccesses : if access in reqAccesses : reqAccesses.remove(access) 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) [EMAIL PROTECTED] _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )