Comment 6 for bug 1074096

I am in favor of removing it entirely.

On Thu, Dec 11, 2014 at 12:48 PM, Kathy Lussier <email address hidden>
wrote:
>
> Given that most sites have indicated they do not use this search option,
> my preference is to remove it entirely. I think it causes confusion for
> users for sites that do not know how to remove it and also causes
> confusion for new libraries moving to Evergreen.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1074096
>
> Title:
> Advanced Search by Bib Call Number Returns 0 Results
>
> Status in Evergreen - Open ILS:
> Triaged
>
> Bug description:
> Evergreen 2.2.2
> Postgres 9.1
> Debian Squeeze
>
> When attempting to query by Advanced Search -> Numeric Search with a
> selection of Bib Call Number an error is encounted as follows:
>
>
> Caught error from 'run' method: Exception: OpenSRF::EX::ERROR
> 2012-11-01T10:22:44 OpenSRF::Application
> /usr/local/share/perl/5.10.1/OpenSRF/Application.pm:209 System ERROR: Call
> to open-ils.storage for method
> open-ils.storage.biblio.multiclass.staged.search_fts.staff.atomic
> failed with exception: Exception: OpenSRF::EX::ERROR
> 2012-11-01T10:22:44 OpenILS::Application::AppUtils
> /usr/local/share/perl/5.10.1/OpenILS/Application/AppUtils.pm:186 System
> ERROR: Exception: OpenSRF::DomainObject::oilsMethodException
> 2012-11-01T10:22:44 OpenSRF::AppRequest
> /usr/local/share/perl/5.10.1/OpenSRF/AppSession.pm:1064 <500> *** Call to
> [open-ils.storage.biblio.multiclass.staged.search_fts.staff.atomic] failed
> for session [1351779763.88325974.147008885412], thread trace [1]:
> DBD::Pg::st execute failed: ERROR: syntax error at or near ")"
> LINE 21: WHERE fe_weight.id IN ()
> ^
> QUERY: SELECT m.source AS id,
> ARRAY_ACCUM(DISTINCT m.source) AS records,
> 1.0/(AVG(
> (COALESCE(ts_rank_cd(xacd12f0_identifier_bib_cn.index_vector,
> xacd12f0_identifier_bib_cn.tsq, 14) * xacd12f0_identifier_bib_cn.weight,
> 0.0))
> )+1)::NUMERIC AS rel,
> 1.0/(AVG(
> (COALESCE(ts_rank_cd(xacd12f0_identifier_bib_cn.index_vector,
> xacd12f0_identifier_bib_cn.tsq, 14) * xacd12f0_identifier_bib_cn.weight,
> 0.0))
> )+1)::NUMERIC AS rank,
> FIRST(mrd.attrs->'date1') AS tie_break
> FROM metabib.metarecord_source_map m
> JOIN metabib.record_attr mrd ON (m.source = mrd.id)
>
>
> LEFT JOIN (
> SELECT fe.*, fe_weight.weight, x.tsq /* search */
> FROM metabib.identifier_field_entry AS fe
> JOIN config.metabib_field AS fe_weight ON (fe_weight.id =
> fe.field)
> JOIN (SELECT
> to_tsquery('identifier', COALESCE(NULLIF( '(' ||
> btrim(regexp_replace($_32475$PN1997.G59$_32475$,E'(?:\\s+|:)','&','g'),'&|')
> || ')', '()'), '')) AS tsq ) AS x ON (fe.index_vector @@ x.tsq)
> WHERE fe_weight.id IN ()
> ) AS xacd12f0_identifier_bib_cn ON (m.source =
> xacd12f0_identifier_bib_cn.source)
> WHERE 1=1
>
> Discussion in chat indicated there may be something missing from a
> configuration table but we are not able to determine the setting(s)
> required to make this query perform as in 2.1 release.
>
> In 2.1 the query would return results based on records that contain
> the call number string entered in one of the MARC call number fields.
> (082, 050 or 092 for example)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1074096/+subscriptions
>