[DM] Acqusition free traversal

[Andreas Jung]

2. Introduction

As everybody who has worked with acquisition knows, acquisition can cause undesired and sometimes surprising effects.

Our experience with such an undesired effect comes from an optimized QueueCatalog. Requests to this QueueCatalog consist of a pair path and a set of indexes -- with the meaning: update indexes for the given path. Unindex requests are represented by path and None, as the QueueCatalog can easily determine whether the object corresponding to the path still exists (it is a reindex request) or no longer exists (it is an unindex). unrestrictedTraverse is used to resolve the path into an object and unrestrictedTraverse uses acquisition. This can easily lead to misclassifications when objects have been deleted.

The QueueCatalog use case is only one of a large class of use cases: acquisition is unwanted whenever one knows that the traversal argument is derived from a physical path. This usually is true for catalogs.

Suppressing acquisition whenever it is known that acquisition should not be necessary, leads to more robust solutions. Therefore, acquisition control should directly be supported by the ITraversable interface.

3. Feature

Extend the OFS.ITraversable interface such that unrestrictedTraverse and restrictedTraverse get an additional parameter noaq=False. If set to True, the traversal does not allow acquisition.

In order to inform traversal hooks whether acquisition is unwanted, the implementation in OFS.Traversable puts a TraversalRequestNoAcquisition key in the pseudo request.

4. Example Use Cases

    *

      Let our QueueCatalog work reliably
    *

      Let the ZCatalog updateCatalog be able to remove ghost doublicates
          o created through copying an object containing the catalog.
    * Enable robust solutions whenever traversal parameters are known
          o to be derived from physical paths or relative physical paths.

5. Notes

    * It is unlikely that the proposal will be accepted -- as
          o

            the ITraversable interface extension will break all its implementations apart from OFS.Traversable.Traversable (which is extended in the same way). Extending interfaces is a difficult problem -- everywhere.

[ChrisW (chris-simplistix)]

'noaq' is a horrible name.
I'm +1 on this change but only if the parameter is changed to be 'acquire', ie:

obj.restrictedTraverse(path,acquire=True) # the default
obj.restrictedTraverse(path,acquire=False) # no acquisiton

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.