I've modified the search process such that searches of single databases do not merge the results. This makes paging faster and allows the user to page to the end of the result set whether there are 281 results, or 12,322. This only works for searches of single databases. Searches on sets of multiple databases will not be able to reach the "end" of their result sets at this time. I've put in another bug (https://sakaiproject.atlassian.net/browse/SLIB-69#icft=SLIB-69) to address that issue for the next tag.

In regards to the ERIC/dogs search: I conducted the search and got a total number of records of 281 and had the same behavior – I searched: got the first 10 -> changed pagesize to 40: got 40 -> hit next page: got records 41-45 of 281 (end of search).

According to the following debug output from the tail end of the X-Server OSID's search process, there are only 45 unique entries in the result set:

... [the X-Server OSID has gone through 270 results already and a "new page" has not been populated by the SearchManager indicating they're all duplicates] ...
DEBUG: getRecordsXML() - presenting records: 000000271-000000280
DEBUG: nextAsset(), XServer.getRecordsXML() returns - assets in queue: 10
DEBUG: nextAsset() [entry] - returned: 271; total: 280; in queue: 9
DEBUG: nextAsset() [entry] - returned: 272; total: 280; in queue: 8
... [the pattern continues] ...
DEBUG: nextAsset() [entry] - returned: 279; total: 280; in queue: 1
DEBUG: nextAsset() [entry] - returned: 280; total: 280; in queue: 0
DEBUG: nextAsset() calling XServer.getRecordsXML() - assets in queue: 0
DEBUG: getRecordsXML() - doing merge_more, set number is 001411
DEBUG: getRecordsXML() - presenting records: 000000281-000000281
DEBUG: nextAsset(), XServer.getRecordsXML() returns - assets in queue: 1

At this point, all the 281 records have been exhausted and only 45 unique records were returned. The X-Server produces no errors and no XServerExceptions (or RepositoryExceptions) are thrown.

It seems that the "total records" number is just very inflated due to duplicates and we may be better off displaying it in a different fashion. For example, we don't want to show 41-45 of 281, but we do want the user to know that the search returned 281 instead of 10,233 results. We could have a separate display for how many "total records" were found with the disclaimer that many of these could be duplicate records. We'll have to have this discussion.

We might want to double-check the duplication algorithm/openURL construction as well to make sure we're not missing something.

I just checked in a fix for that problem. SearchManager was using the wrong "page-size" setting.

The other issue is still active. I searched in ERIC (via xserver osid) for "dogs". I got the first 10. Then changed the page-size to 40. That showed 1-40 of 261. Then clicked next page. That showed 41-45 of 261. So there was an error in record 46 or so. I'd appreciate if both Gaurav and Steve looked at that record (assuming the same record causes an error for web2bridge osid).

This may reflect a different problem.

Here at IU (with the Web2 OSID): I search EBSCO ERIC for dogs, and I see 20 results. If I then reset the page size to 50, a search is initiated, and I wind up with this:

Viewing 1 - 40 of 263

There was no error on the OSID side - after the page size change, it just looked up 20 additional records, not the 30 I would have expected.

Susan mentioned the following search in another ticket: Search "ERIC" for "painting and drawing primary". The paging widget indicates that 32 items can be retrieved, but the search consistently fails after retrieving 25 results. Why?