> When using pagedresults with a subordinate database, the control
> returned searchResDone is corrupted.
AFAIK, paged results is not supposed to work with glued databases, as its
current implementation in both back-bdb/back-hdb and back-sql relies on
internal properties of the storage to keep track of the state of a
search. The most appropriate behavior would be to ignore the control, if
not critical, or reject the operation, if critical.
I take this ITS as an action to prevent paged results from working when
impacting more than one glued database.
I disagree. The fact that databases are glued should in no way prevent paged
results from working. After all, the glue only talks to one database at a
time. As such, the paged results control's relevance never spans more than a
single database at a time. The bug is that after one database has provided all
of its entries in response to a request, its response control should be
nullified. I.e., a particular database's response control is only needed if
that database isn't finished sending entries. Once it has sent all of its
entries, it's no longer relevant.
Overall the paged results implementation is a suboptimal design; the frontend
should do all of the page counting/tracking. It should only ask the backend to
provide a state cookie when the current page is full and there are more
entries to return.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/