[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6507) backglue and paged results issue

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 Clarke - jonathan@phillipoux.net
Ldap Synchronization Connector (LSC) - http://lsc-project.org