Web client: Z39.50 search result display issues

Bug #1745249 reported by tji@sitka.bclibraries.ca
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

web client of EG version 3.x

1. The number of rows on each page (Row xx) is not working. For example, with Row 10, the first page may display more than 10 records.

2. Flipping to next page by clicking the down pointed arrow, then choosing 2 may result in more than 10 records, though the top record is numbered 11.

3. I encountered cases that some records are not displayed. For example, when total hits are 33, only 31 are displayed. When total hits are 14, only 12 can be displayed.

4. When flipping to next page, it looks like the search is redone. The total hits was changed to 0 and the list of records disappeared, then the Total hits started to increase and the records to show up.

5. The same thing happens when using the forward/backward arrows to flip through pages or changing the number of rows per page (use the down pointed arrow in Rowxx).

Revision history for this message
Elaine Hardy (ehardy) wrote :

I am not seeing this behavior when retrieving records from OCLC. Row numbering is consistent for me.

Are you searching OCLC? If so, is there a specific search you are seeing it with (I searched Title: Left Hand of Darkness)

Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

I searched various targets for different terms with various result sizes (from a few to a few hundred, up to thousand). I tried all the Rowxx. It does not seem these parameters matter.

Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

page 2

Revision history for this message
Elaine Hardy (ehardy) wrote :

I am definitely not seeing the issue with OCLC. Whether I look at 5 or 100 rows, it maintains the correct numbering as I page through. We do not use any other bib source.

I searched title game of thrones and retrieved 3183 records from OCLC. The list numbering is fine but the search return is limited to 2500 and does not retrieve the last 683 records.

Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

Thanks, Elaine, for testing it.

I tried searching a single source. The list numbering seems fine. But when I selected two sources. I see the issue. It seems the issue is with results from multiple sources.

I have a test case with 31 results from two sources, one has 4, the other 27. The number of rows per page is 10. The first page displays 14 records, 4 from one source, 10 from the other. Flipping to next page I got 10 records from a single source. On the third page, there are only 7 records from one source. It looks to me the 4 records from the other source are 'mistakenly' displayed on the first page.

Revision history for this message
Elaine Hardy (ehardy) wrote :

We only use OCLC as a source, so I can't test that for you.

Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

Thanks, Elaine. Your finding is very helpful already. :-)

Revision history for this message
Felicia Beaudry (fbeaudry) wrote :

I am also seeing this behavior in 3.0.3 when searching multiple sources. My search had 271 total hits. The interface should be showing 10 rows, but I'm seeing 21. When I page forward using the arrow (next to actions), I see a Total Hits of 27, but only 10 display. When I use the page dropdown, the message is No Items to Display.

Changed in evergreen:
status: New → Confirmed
Andrea Neiman (aneiman)
tags: added: cataloging z3950
Meg Stroup (mstroup)
tags: added: webstaffclient
tags: removed: webstaffclient
Revision history for this message
Andrea Neiman (aneiman) wrote :

disregard previous comment, I was overzealous with copy/paste :)

In our spec for Sprint A of Acq, we stated:

"There is no sensible interface-based fix for this issue, since it will require a rethink of the
underlying API call. The problem is a general one for federated searches, where some
compromises may need to be made and behavior agreed upon. We recommend approaching
this as a separate project." (pg. 5)

https://yeti.equinoxoli.org/dev/public/techspecs/angacq_sprintA_202305.pdf

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.