directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: search vs enumeration
Date Wed, 11 Jul 2007 20:16:05 GMT
Yeah sort of.  You're wrapping one enumeration kind in another.  This
partition implementation
incidentally does all this to avoid having to cache large numbers of
entries.  It uses enumerations on
indices to pull candidates which are each checked for evaluation one at a
time instead of buffering.
This way a search request at most has a couple entries in memory at one time
instead of the entire
result set.

Alex

On 7/11/07, Barber, Dan (Contractor) <Dan.Barber@polycom.com> wrote:
>
> All,
>
>
>
> As I'm trying to understand the architecture of the btree/jdbm partition
> implementation I need to understand the difference between these two
> issues. Let me just make sure I've broken things out properly.
>
>
>
> When the call:
>
>
>
>             underlying = searchEngine.search(
>
>                         opContext.getDn(),
>
>                         ((SearchOperationContext)opContext).getEnv(),
>
>                         ((SearchOperationContext)opContext).getFilter(),
>
>                         searchCtls );
>
>
>
> is made in the search code for the partition, that is returning a list
> of entries that satisfy the search condition specified by the dn, env,
> filter and searchCtls.
>
>
>
> When the call:
>
>
>
>         return new BTreeSearchResultEnumeration ( attrIds, underlying,
> this, attributeTypeRegistry );
>
>
>
> is made at the end of the search function, that returns a
> NamingEnumeration that allows us to get the requested attributes for
> each entry in underlying, which is the result of the search.
>
>
>
> Is that pretty much how those two break out?
>
>
>
> Thanks,
>
>
>
> Dan
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message