Refactor interceptors so only one SearchRequestFilteringEnumeration is used

• Key: DIRSERVER-677
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Trivial
• Assignee: Alex Karasulu
• Reporter: Alex Karasulu
• Component/s: core
• Affects Version/s: 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
• Fix Version/s: 2.0.0

Description

We need to clean up the number of nested (wrappings of) SearchResultFilteringEnumerations. It's best if we relocate the code that wraps Partition specific Enumerations with this into the Nexus. There we can add Filters to a single SearchResultFilteringEnumeration. Right now a few interceptors wrap 3 layers of SearchResultFilteringEnumerations. Here are the offending interceptors:

(1) DefaultAuthorizationService
(2) SubentryService
(3) CollectiveAttributeService

Creating a new SearchResultFilteringEnumeration everytime costs us about 2% total of processing time in search operations. We could save a total of 4% and improve the code.

Regarding addFilter usage
------------------------------------------

Note that some interceptors, these 3, need to add filters at searh construction time rather than at interceptor service init time. These services can use the addFilter() interface of the SearchResultFilteringEnumeration but this interface must make sure the first prefetched entry is evaluated otherwise the first entry will be returned even if your filter rejects it.

Comments

[Emmanuel Lecharny]

Postponed to 1.5.1

[Emmanuel Lecharny]

Far too complex to be done for 1.5.1.

Postponed to 1.5.2

[Emmanuel Lecharny]

Postponed.

[Alex Karasulu]

This is the case now after having moved to using Cursors after the bigbang