[Zope] Re: Index Problem - Index randomly breaks/changes

[Ryan Smith]

Tres, let me start by saying thanks for helping me look into this.

> Note that a FieldIndex is likely not to do what you want for
> multi-valued attributes, such as lists or tuples: you probably want a
> KeywordIndex, which allows you do supply operators such as 'and' and 'or'.
>

I considered a KeywordIndex at first.  It can't do what I want though,
I would need to mix and, or's and not's to do what I need to do.


> That isn't enough information: we really need to see the arguments
> being passed to the catalog's 'search' or 'searchResults' methods.
>
> You need to show the filter you are using, because nothing in stock Zope
> / CMF / Plone works the way you describe.

In Products.CMFPlone.CatalogTool.py  In the function searchResults has
this at the bottom -
return ZCatalog.searchResults(self, REQUEST, **kw)

I added the following code to the bottom of this function
results = ZCatalog.searchResults(self, REQUEST, **kw)
usrAccesses = getUserAccesses(user)
    for index in reversed(range(len(results))):
        if results[index].getAccess:
            reqAccesses = results[index].getAccess

        for access in usrAccesses :
            if access in reqAccesses :
                 reqAccesses.remove(access)

        if len(reqAccesses):
             del results[index]

return results
---------------------------------------------------------------------------
This code does what I need it to do.  The problem is
reqAccesses = results[index].getAccess
Sometimes has the wrong accesses.


> I think you need to give us a script to reproduce the behavior you are
> seeing, e.g.:
>

I will set up and run the script you sent.  The thing is, more than
likely it will produce the expected results.  I don't always see the
behavior.
Before setting up your test cases, here are the actual results from
one of our test servers.

The Index created is called 'getAccess', the metadata field created is
'getAccess'

Created the following objects.  The suffix on each file name
desicribes what I set the access attribute is.  (a==alpha, b==beta,
g==gamma, n==none of them)
/Plone/test-area/filen
/Plone/test-area/filea
/Plone/test-area/fileab
/Plone/test-area/fileabg
/Plone/test-area/fileag
/Plone/test-area/fileg

In the ZMI under portal_catalog, Advanced tab, I click "Update Catalog".
In a seperate window I refresh portal_catalog->Indexes->getAccess->Browse

----------------------------------------------------------------------
Now sometimes the getAccess Index has the following which is correct -
['']
/Plone/test-area/filen

['alpha', '']
/Plone/test-area/filea

['alpha', 'beta', '']
/Plone/test-area/fileab

['alpha', 'beta', 'gamma', '']
/Plone/test-area/fileabg

['alpha', 'gamma', '']
/Plone/test-area/fileag

['gamma', '']
/Plone/test-area/fileg
-----------------------------------------------------
Other times it has this, which is incorrect -
['alpha']
/Plone/test-area/filea
/Plone/test-area/fileag

['alpha', 'beta', '']
/Plone/test-area/fileab

['alpha', 'beta', 'gamma', '']
/Plone/test-area/fileabg

['gamma', '']
/Plone/test-area/fileg
-----------------------------------------------------------------

As you can see the one that is wrong changed
['alpha', ''] to ['alpha']  which caused it to grab more than it should of
And it is missing
[''] and ['alpha', 'gamma']
-----------------------------------------------------------------------------------------

>
> The two "values" you are seeing (I'm willing to bet money that the
> transaction ID isn't the same) are two different ZODB connections: some
> requests get one connection from the pool, while others get another.
>
If this is the case could there be a reason why one of the connections
from the pool always results in something different?

- Ryan