Filter by audience improperly excludes ' ' (blank space) from search results

[Ben Ostrowsky]

Using the 2.0.4 community demo server, search for keyword 'Cooking', item type 'Books', literary form 'Non Fiction'. I get two results: http://75.101.133.94/opac/en-US/skin/default/xml/rresult.xml?if=&it=a%2Ct&bl=&lf=0%2C%20&a=&la=&cl=&d=0&l=1&s=rel&sd=asc&adt=ml&tp=&t=keyword%3A%20Cooking&av=&rt=multi

Go back and add audience 'Adult' as a condition; both results disappear: http://75.101.133.94/opac/en-US/skin/default/xml/rresult.xml?if=&it=a%2Ct&bl=&lf=0%2C%20&a=e%2C%20&la=&cl=&d=0&l=1&s=rel&sd=asc&adt=ml&tp=&t=keyword%3A%20Cooking&av=&rt=multi

Both bibs have a blank space (' ') in the 008/22.

Line 168 of advanced_global.xml (in trunk) says that both 'e' and ' ' should be included in the filter (and the URL includes the argument a=e%2C%20 ('a=e, ') but this isn't working.

[Ben Ostrowsky (sylvar)]

The search form appears to be sending the correct data to the server. The console says:

dbg: Search args: {"org_unit":4,"depth":2,"limit":10,"offset":0,"visibility_limit":3000,"default_class":"","item_type":["a","t"],"audience":["e"," "],"lit_form":["0"," "]}

[Ben Ostrowsky (sylvar)]

On a different test server, I cranked up the postgres logs and found that the statement did not include an audience of ' ':

2011-04-14 14:28:13 EDT LOG: duration: 121.049 ms statement: SELECT * /* bib search */
                  FROM search.query_parser_fts(
                            1::INT,
                            0::INT,
                            $core_query_26879$SELECT m.source AS id,
                ARRAY_ACCUM(DISTINCT m.source) AS records,
                (AVG(
                        (rank(x8e01718_keyword.index_vector, x8e01718_keyword.tsq) * x8e01718_keyword.weight
                                         * /* word_order */ COALESCE(NULLIF( (naco_normalize(x8e01718_keyword.value) ~ (naco_normalize($_26879$Cooking$_26879$))), FALSE )::INT * 10, 1))
                ) * COALESCE( NULLIF( FIRST(mrd.item_lang) = $_26879$eng$_26879$ , FALSE )::INT * 5, 1))::NUMERIC AS rel,
                (AVG(
                        (rank(x8e01718_keyword.index_vector, x8e01718_keyword.tsq) * x8e01718_keyword.weight
                                         * /* word_order */ COALESCE(NULLIF( (naco_normalize(x8e01718_keyword.value) ~ (naco_normalize($_26879$Cooking$_26879$))), FALSE )::INT * 10, 1))
                ) * COALESCE( NULLIF( FIRST(mrd.item_lang) = $_26879$eng$_26879$ , FALSE )::INT * 5, 1))::NUMERIC AS rank,
                FIRST(mrd.date1) AS tie_break
          FROM metabib.metarecord_source_map m
                JOIN metabib.rec_descriptor mrd ON (m.source = mrd.record)

                LEFT JOIN (
                        SELECT fe.*, fe_weight.weight, x.tsq /* search */
                          FROM metabib.keyword_field_entry AS fe
                                JOIN config.metabib_field AS fe_weight ON (fe_weight.id = fe.field)
                                JOIN (SELECT
                                to_tsquery('keyword', COALESCE(NULLIF( '(' || btrim(regexp_replace(split_date_range(naco_normalize($_26879$Cooking$_26879$)),E'(?:\\s+|:)','&','g'),'&|') || ')', '()'),
x.tsq)
                ) AS x8e01718_keyword ON (m.source = x8e01718_keyword.source)
          WHERE 1=1

                AND mrd.audience in ($_26879$e$_26879$)

                AND mrd.item_type in ($_26879$a$_26879$,$_26879$t$_26879$)

                AND mrd.lit_form in (E'0')

                AND ((x8e01718_keyword.id IS NOT NULL))
          GROUP BY 1
          ORDER BY 4 DESC NULLS LAST, 5 DESC NULLS LAST, 3 DESC
          LIMIT 10000
        $core_query_26879$::TEXT,
                            $${}$$::INT[],
                            $${}$$::INT[],
                            NULL::INT,
                            1000::INT,
                            10000::INT,
                            'f'::BOOL,
                            'f'::BOOL
                        );

This seems to implicate (as Mike Rylander guessed) the filter parser.

[Jason Stephenson (jstephenson)]

Given the age of the bug and that it is reported on a deprecated branch, is this bug worth pursuing?

Is it still a problem in current releases and if so is it worth fixing?

[Jason Stephenson (jstephenson)]

Pending confirmation in 2.1+/TPAC.

[Sarah Childs (sarahc)]

I found that searches in using 2.2 in Indiana still don't include records coded as blank in searches filtered to an audience of adult.

I wish I had known they were supposed to. I would have filed a ticket on this years ago.

[Terran McCanna (tmccanna)]

This was working for us in 2.5 but since we upgraded to 2.7.2 yesterday, it is no longer working.

We still have a test 2.5 server with a copy of our data so we can run comparative tests between the two. The result set for keyword "pregnancy audience( )" (with a blank space in it) on 2.5 gives us 2423 results and on 2.7 gives us 0 results.

Likewise, if we do multiple audience types - "pregnancy audience( ,e,f,g)" on 2.5 gives us 2552 results and on 2.7 gives us 171 results.

[Terran McCanna (tmccanna)]

See newer bug report:

https://bugs.launchpad.net/evergreen/+bug/1414112

[Ben Shum (bshum)]

Since the newer bug report was merged, and this one is past, I'm marking it as duplicate and closing this one.