ando@sys-net.it wrote:

...

When using pagedresults with a subordinate database, the control value of the 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.