[OPEN-ILS-GENERAL] Inconsistent/wrong search results when searching by location in TPAC

Hardy, Elaine ehardy at georgialibraries.org
Wed Jan 22 13:37:45 EST 2014


I miss the shelving location search filter on advanced search when scoped
for a specific branch.

Elaine

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304

404.235-7128
404.235-7201, fax
ehardy at georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines


-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Mike Rylander
Sent: Wednesday, January 22, 2014 12:44 PM
To: sarahc at zionsville.lib.in.us; Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Inconsistent/wrong search results when
searching by location in TPAC

Sarah,

There may be implementation-specific tuning that would improve the
situation for you.  I'd recommend having your support vendor look into
that.  There are cases where large data sets need an index and small ones
do not, and we can't always predict where those will be or how to define
"large" in every case.  I would not be surprised if this was one such
case, but it's not guaranteed either.


On Wed, Jan 22, 2014 at 12:23 PM, Sarah Childs
<sarahc at zionsville.lib.in.us> wrote:
> We experience the same thing when we try to narrow a search to a 
> particular shelving location. It generally just times out. I assume 
> that approach works for single installations of Evergreen, and perhaps 
> even small consortiums, but it's basically worthless for us.
>
> ---
> Sarah Childs
> Technical Services Department Head
> Hussey-Mayfield Memorial Public Library
> 250 North Fifth Street
> Zionsville, IN 46077
> 317-873-3149 x13330
> sarahc at zionsville.lib.in.us
>
>
> On 2014-01-21 20:55, Mike Rylander wrote:
>>
>> Justin,
>>
>> The reason that search is slow is that you're effectively asking the 
>> system to return all bib records, then pull up all their copies, then 
>> pull up those copies' shelving locations, and finally filter out 
>> records that do not have copies that do not have shelving locations 
>> in your list.  That is exactly the reason I built the new items 
>> functionality.
>>
>> With a little elbow grease, one could certainly use one of the many 
>> XML format output options available for use with the new items list 
>> to re-sort them however one would like, and display them exactly as 
>> one would wish.  Just try replacing "html-full" with "atom" or "rss2".
>>
>> In fact, you could even use the OPAC to do the heavy lifting for you 
>> if you were to extract the record IDs from the XML new item feed and 
>> built a search using the record_list() filter and the sort(titlesort) 
>> operator.
>>
>> Perhaps, with likely less total effort, an opac format could be added 
>> to the new item list, along with support for additional query 
>> components (such as sorting) in the case of the opac format.  A 
>> simple redirect would do.
>>
>> A wishlist bug sounds like a good idea.  Perhaps time or funding will 
>> materialize.
>>
>>
>> On Tue, Jan 21, 2014 at 6:21 PM, Holly Brennan 
>> <haderhold at ci.homer.ak.us>
>> wrote:
>>>
>>> "This improves the presentation and allows for title sorting but the 
>>> search takes *forever* to return and the results are always way off 
>>> and frequently do not return any results at all. Having just tried 
>>> it, TPAC claims there are no results whatsoever. Two or three page 
>>> refreshes later it turns up
>>> 353
>>> items. According to the DB we have 1951 distinct bibs with items in 
>>> those locations.
>>>
>>>
>>>
>>> Has anyone else seen this behavior? Is there an open bug on it? 
>>> Should there be?"
>>>
>>>
>>>
>>> Weird. We, too, use "New Books" as a location for searching. I just 
>>> pulled up the whole batch of new adult books in our library (5,070 
>>> records) without a problem. It took maybe one second to load the 
>>> page.
>>>
>>>
>>>
>>> I didn't find a delay using your search method, either.
>>>
>>>
>>>
>>> I know this is sort of non-information, but it could be helpful so I 
>>> chimed in. Let us know if you solve the problem!
>>>
>>>
>>>
>>> -Holly
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Holly Brennan
>>>
>>> Library Technology Specialist
>>>
>>> Homer Public Library
>>>
>>> 907-235-3180 (main)
>>>
>>> 907-435-3154 (direct)
>>>
>>> hbrennan at cityofhomer-ak.gov
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: open-ils-general-bounces at list.georgialibraries.org
>>> [mailto:open-ils-general-bounces at list.georgialibraries.org] On 
>>> Behalf Of Justin Hopkins
>>> Sent: Tuesday, January 21, 2014 12:56 PM
>>> To: Evergreen Discussion Group
>>> Subject: [OPEN-ILS-GENERAL] Inconsistent/wrong search results when 
>>> searching by location in TPAC
>>>
>>>
>>>
>>> Hi guys,
>>>
>>>
>>>
>>> Like probably many others, we have noticed that Evergreen is lacking 
>>> a really good "new books" feature. We've explored this:
>>>
>>>
>>>
>>> http://missourievergreen.org/opac/extras/browse/html-full/item-age/S
>>> RLWA
>>>
>>>
>>>
>>> The presentation of this option isn't very good though, and ideally 
>>> we'd have the ability to sort by title.
>>>
>>>
>>>
>>> It just so happens that our library who is most interested in this 
>>> has a shelving location at each of their branches called New Books. 
>>> So we tried this approach using search syntax:
>>>
>>>
>>>
>>>
>>> http://missourievergreen.org/eg/opac/results?fi:item_type=&query=loc
>>> ations(1307,1308,1309,1310,1311,1558,1559)+&qtype=keyword&locg=174&s
>>> ort=titlesort)
>>>
>>>
>>>
>>> This improves the presentation and allows for title sorting but the 
>>> search takes *forever* to return and the results are always way off 
>>> and frequently do not return any results at all. Having just tried 
>>> it, TPAC claims there are no results whatsoever. Two or three page 
>>> refreshes later it turns up
>>> 353
>>> items. According to the DB we have 1951 distinct bibs with items in 
>>> those locations.
>>>
>>>
>>>
>>> Has anyone else seen this behavior? Is there an open bug on it? 
>>> Should there be?
>>>
>>> Regards,
>>>
>>> Justin
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Mike Rylander
>>  | Director of Research and Development  | Equinox Software, Inc. / 
>> Your Library's Guide to Open Source  | phone:  1-877-OPEN-ILS 
>> (673-6457)  | email:  miker at esilibrary.com  | web:  
>> http://www.esilibrary.com



--
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source  | phone:
1-877-OPEN-ILS (673-6457)  | email:  miker at esilibrary.com  | web:
http://www.esilibrary.com


More information about the Open-ils-general mailing list