Bug 5515 - Leading 'and' in search never returns a result
Summary: Leading 'and' in search never returns a result
Status: RESOLVED DUPLICATE of bug 9233
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: PC Linux
: P5 - low major (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 9234
  Show dependency treegraph
 
Reported: 2010-12-16 23:16 UTC by Bob Ewart
Modified: 2019-04-28 23:35 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Ewart 2010-12-16 23:16:28 UTC
Searching on "and the band played on" returns no results.  There are 3 biblios for that title, a book, a DVD and a video.  

The error log shows:
[Thu Dec 16 17:18:27 2010] [error] [client 127.0.0.2] [Thu Dec 16 17:18:27 2010] search.pl: WARNING: query problem with kw,wrdl,rtrn=and band played  ZOOM error 10014 "CCL parsing error" (addinfo: "Search word expected") from diag-set 'ZOOM' at /usr/share/koha/lib/C4/Search.pm line 346., referer: http://127.0.0.2:8080/cgi-bin/koha/mainpage.pl

This happens with Koha 3.02.01 on openSUSE 11.3 (32-bit and 64-bit) and on Debian squeeze/sid (64-bit) with zebra.

Searching on 'the band played on' gets all three records.
Comment 1 Chris Cormack 2010-12-17 01:00:53 UTC
I have found the problem

In our ccl.properties file around line 1105 we have

@and and +

Which sets the and operater to be and or + .. which means when we pass and in our query it gets evaluated as an operator. To fix this

We can change that to something like

@and +++

Now +++ is the operator for and, and then we need to change C4/Search.pm to set +++ instead of and in the ccl when we want to and terms together so

ti=fish and author=bob would be ti=fish +++ author=bob
Comment 2 Galen Charlton 2011-01-05 23:03:40 UTC
Semi-related - "not" in a basic search is treated as an operator, not a search term, which can produce unexpected results.  Thus, @not (and for completeness, @and and @or) could be changed as well.

This does beg the question of what the best search grammar (from the POV of the user) should be, so this would be an area for configuration hooks to be added.
Comment 3 Ian Walls 2011-09-15 15:18:56 UTC
My research is showing this to be an issue with the truncation; if QueryAutoTruncate is off, no error message is generated.

The error seems to occur when searching kw,wrdl,rtrn:and whatever

With QueryAutoTruncate off, the weighting kicks in, and the search terms are wrapped in quotes, preventing the parse error.
Comment 4 Mark Tompsett 2012-07-17 09:34:33 UTC
Confirmed this in 3.6.3 :)
What is the recommended course of action?

[Tue Jul 17 16:38:23 2012] [error] [client 192.168.100.2] [Tue Jul 17 16:38:23 2012] opac-search.pl: WARNING: query problem with kw,wrdl,rtrn=and the word came with power and branch=MNL ZOOM error 10014 "CCL parsing error" (addinfo: "Search word expected") from diag-set 'ZOOM' at /usr/share/koha/lib/C4/Search.pm line 355.

I changed the QueryAutoTruncate from "automatically" to "only if there is a *", and the problem went away. However, if I tried to query "and the word came with pow*", it would generate the same error. Given that our users don't think of using *, I'm leaving it changed, but it would be nice not to have the error with starting with "and" and having an asterisk.
Comment 5 Marc Véron 2015-04-26 20:25:11 UTC
I had similar problems with current master.

And the band played -> No results
the band played ->results

Beauty and the beast -> results
and the beast -> no results
Beauty and -> no results
Comment 6 Marc Véron 2017-08-24 09:11:23 UTC
Still valid on current master

Title:
And the music speaks

Search for:
And the music speaks => fail
the music speaks => success

Title:
Max and Moritz

Search for:
Max and Moritz => success
and Moritz => fail
Comment 7 Katrin Fischer 2019-04-28 23:35:33 UTC

*** This bug has been marked as a duplicate of bug 9233 ***