[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[Fwd: Paged Results and limits]
- To: openldap-devel@OpenLDAP.org
- Subject: [Fwd: Paged Results and limits]
- From: Pierangelo Masarati <ando@sys-net.it>
- Date: Fri, 09 Apr 2004 16:33:05 +0200
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Forwarded from -committers; follow-ups are coming.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
--- Begin Message ---
I'm about to complete the commit of additional limits for paged results
control.
Currently, the control is only implemented in back-bdb, but I'm moving
the limits
on the control outside of it, into the limits_check() function that sets
the time and
size limits for the execution of a single search (which corresponds to
one page
when the control is used). In the future, this could help in moving the
control to the
frontend, if advisable.
The current implementation interprets the size limits as a size limit on
the single
page, so a request for a page size that is smaller than the limit
results in a search
that can span the entire database without any limits, apart from the
"unchecked"
test on the number of candidates.
The pagedResults control enabled two extra limits: one on the max size
of a single
page that was different from the basic search size limit, and the other
intended as
a means to hide the estimate of the remaining entries to be returned.
I'd leave this behavior as the default, and add a new limit on the total
number
of entries that a search with the pagedResults control can return. I'd
interpret
the request for a page as an explicit limit set by the user, so the
"hard" limits are
used instead of the "soft", and the new "prtotal" limit as a means to
introduce
an overall "hard" limit.
All the limits are now moved to the limits_check() function, so the
search functions
only see a size limit and act accordingly.
Commit to come soon; still working on cleanup.
Comments?
--- End Message ---