Le 11/12/14 05:32, amit nanda a écrit :
> Hi,
>
> I would like to get the total count of entries under a container.
> I application will have around 100000 entries, i can't get a direct way to
> to this.
Plain normal.
>
>
> Here is a sample of workaround the code i wrote
>
> Stopwatch timer = Stopwatch.createStarted();
>
> final SearchControls searchControls = new SearchControls();
> searchControls.setSearchScope(SearchControls.ONELEVEL_SCOPE);
> searchControls.setReturningAttributes(new String[]{"uid"});
>
> int count = 0;
> String filter =
> "(&(objectClass=asoc-es)(|(asoc-es-state=Karnataka)(asoc-es-city=Ontario)(asoc-es-county=England)"
> +
> "(asoc-es-priority=5)))";
>
> count += ldapTemplate.search("ou=services,ou=configuration,ou=system",
> filter,
> searchControls, new AttributesMapper<Object>() {
> @Override
> public Object mapFromAttributes(Attributes attributes) throws
> NamingException {
> return "";
> }
> }).size();
>
> timer.stop();
>
> Logger.getLogger("Ldap-Client").info("Count = : " + count);
> Logger.getLogger("Ldap-Client").info("Duration = : " + timer);
>
>
> I tried this with around 20,000 entries, time taken was around 4 seconds,
> which is bit more that my requirement.
I can imagine. What happens is that you will get back the 20 000
entries, which is obviously costly. You can slightly improve the time by
not reqquesting any of the entry content, by doing a search asking for
"1.1" attribute (this is a 'special' attribute asking the server to
return ony the DN, skiping all the attributes. That would save a bit of
network.
>
> I also see that in PagedResultsDirContextProcessor I see that there is a
> getResultSize(), which should give us the total count according to the doc,
> but this doesn't seems to be working for me.
This is not mandatory :
"In the control returned to the client, the size MAY be set to the
server's estimate of the total number of entries in the entire result
set. Servers that cannot provide such an estimate MAY set this size to
zero (0)."
(RFC 2696).
That would be a good addition to provide such an estimate, we have this
number internally. The problem is that the estimate will always be an
uper bound, and is likely to be the total number of entries stored in
the server (in other words, we don't count the entry set, we roughly
guess this number based on many elements, and I don't really have time
to explain how it works, it would take me an hour ;-)
>
> Is there any way i can get the total count, faster than this.
Nope.
Now, the question is : why do you want such a number ?
Side remark : it would be quite interesting to be able to provide such a
*real* number of entries that would be returned, without actually
returning any of those entries. The work would be done on the server,
and returned as a control.
That would be appreciated if you could fill a JIRA for that.
Thanks !
