Antwort: Re: reply: [Bug 31141] Changed - LDAPSearchResults getCount() methodreturns incorrect value

[joerg_schaefer@westlb.de]

Hi,

I would like to comment on the definition of "getCount()" in the ldapjdk API.
 I understand your rationale for providing asynchronous access, but I would
argue for a renaming the method as its confusing and exposes implementation
details to the client and for adding a convenience method as described in the
email below.
Cheers
Joerg




miodrag@netscape.com (Miodrag Kekic) on 03/14/2000 11:38:59 PM

An:   Jörg Schäfer/D/WLB@WLB
Kopie:
Thema:    Re: reply: [Bug 31141] Changed - LDAPSearchResults getCount()
      methodreturns incorrect value


Joerg,
I agree that the name is misleading, you are not the first one that ran into the
problem. However, ldapjdk APIs are now controlled by the ietf-ldapext working
group
and we can not any more just go and change them. There is an internet draft
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-10.txt
where
LDAPSearchResults.getCount() is
defined as

  " Returns a count of the entries in the search result. If the search is
   asynchronous (batch size not 0), this reports the number of results
   received so far."

These APIs are subject to public discussion. You can add yourself to the mailing
list ietf-ldapext@netscape.com where you can discuss ldap java API.

Regards,
Miodrag

joerg_schaefer@westlb.de wrote:

> Hi there,
>
> OK, understood, many thanks. But I still think this is not a feature but a
bug,
> or bad behaviour, to say the least.
> We have a public method that exposes implementation details such as the status
> of the internal result queue to the client. This should be avoided in general.
> The naming is also misleading - I saw example code that mistakenly believed in
> what I believed would be returned. Thus, I would suggest some renaming at
least
> and maybe adding a convenience-method returning the business relevant
> information e.g. the total number of entries that match the search filter,
too!
> (if this requires blocking - ok, there is no alternative.)
> By the way - is it appropriate to suggest this here?
> Cheers
> Joerg
>
>  ------- Additional Comments From mcs@netscape.com  2000-03-09 10:19 -------
>   Reassigned to Miodrag.
> +
> + ------- Additional Comments From miodrag@netscape.com  2000-03-13 18:08
> -------
> + This is a normal behavior. LDAPSearchResults.getCount() returns the number
of
> + currently available search results in the search result queue, rather than
the
> + total number of entries that match the search filter.
> +
> + When the directory sends a new search result, the result gets queued and the
> + search result count is incremented. As you read search results from
> + LDAPSearchResults, one at a time, the search result count gets decremeneted.
> +
> + Only if you set the batch size in LDAPSearchConstrains to 0 --means search()
> + should wait for all results to be received before proceeding --, you'll see
> the
> + exact count of found entries.
> +
> + By default the batchSize is 1, which means results are to be processed as
they
> + come in. LDAPSearchResults.hasMoreElements() blocks until the batchSize
number
> + of  results is received.
> +