Le 08/04/2010 15:59, masarati@aero.polimi.it a écrit :

...

Just one weird case left. Considering the same setup as described above (back null with 2 back ldap glued underneath): a search with pagedResults and a page size of 3 (the exact number of results returned by each back ldap), we get:

• a first page with the 3 results from back ldap 1
• a second page with 3 results from back ldap 2 (so far, so good)
• but then this last result also has a pagedResults cookie, and the search

can go on and on, returning the same 2nd page.

Presumably this is related to the patch allowing pagedResults to cross two databases. If the first returns an empty cookie (no more results), a new cookie is added. However, this should not be done if the last database returns no more results.

It's related to the fact that I need to parse the cookie when it's not parsed yet, to see whether it's empty. So I'm now parsing it also when working with the last database, which needs to be treated specially (i.e. it must let the empty cookie pss thru). Fixed, will commit in a moment.

Thanks, p.

Ah yes, just saw this. Sorry, my email seems to be slow today (weird).

Similar to my patch, but I'm unsure about the second part:

} else if ( op->o_bd != gi->gi_n[0].gn_be ) { /* if cookie not empty, it's again this database's turn */ op->o_conn->c_pagedresults_state.ps_be = op->o_bd; }

If the cookie is not empty, then it should again be this database's turn, even it this is this last database.

This makes a search that stops in the middle of results from last database with a valid cookie fall back to the first database on continuation, and thus loop forever.

Would you consider removing the else if?

Jonathan