Bug 1807 - ':' character blocks search ; search () give odd results
: ':' character blocks search ; search () give odd results
Status: ASSIGNED
Product: Koha
Searching
: rel_3_4
: All All
: PATCH-Sent blocker (vote)
Assigned To: Chris Cormack
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-01-30 11:50 UTC by Frédéric Demians
Modified: 2010-07-13 20:13 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---


Attachments
Patch to fix searching on () (1.47 KB, patch)
2009-12-12 08:17 UTC, Chris Cormack
Details | Diff
Patch to stop : blocking searches (861 bytes, patch)
2009-12-12 09:08 UTC, Chris Cormack
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:34:49 UTC


---- Reported by frederic@tamil.fr 2008-01-30 23:50:43 ----

SEARCH            RESULT
black panthers    Some biblio records
black : panthers  Nothing



---- Additional Comments From henridamien@koha-fr.org 2008-02-01 00:43:30 ----

this is owed to the fact that no matter what is before, : or = in search boxes
are considered as ccl commands :
here index black contains panther.

This is a bug in this case but is a feature for big search box




---- Additional Comments From frederic@tamil.fr 2008-02-01 01:30:14 ----

You're correct. Being able to send CCL queries directly to Zebra search
engine is a great feature for power users. But it doesn't make sense for
end user, especially in a Google-Like search box. End users search for books
typing title and subtitle separated by :.

A solution could be to allow : interpretation only in Advanced search when
Keyword index is selected. 



---- Additional Comments From henridamien@koha-fr.org 2008-03-15 15:40:56 ----

Moving criticity up Since this can cause ppl not to be confident in our search.
indeed, if they copy paste a title which contains : or = then they CANNOT find
it !!!!



---- Additional Comments From jmf@liblime.com 2008-05-19 13:43:48 ----

The right way to fix this would be to assign a specific subset of ccl-style
parameters such as ti: for title, su: for subject, and only treat those : as
assignment operators, and the rest of the ':' and '=' as keyword terms. I'll
take a look at what this will take to accomplish.



---- Additional Comments From paul.poulain@biblibre.com 2008-06-05 06:04:51
----

couldn't we request that an explicit ccl query start by "ccl:"

so "title = bear" => search "title & bear"
and "ccl: title=bear" => CCL search on title for value "bear"

I think that a poweruser entering an equation can understand he must start it
by ccl !



---- Additional Comments From drdrulm@yahoo.com 2008-06-12 15:31:33 ----

: is nothing, try searching on:

cats \

(with that slash)

I get at:
http://smfpl.dev.kohalibrary.com/cgi-bin/koha/opac-search.pl?q=cats\
_____________________________________________________________________

Koha error

The following fatal error has occurred:

Trailing \ in regex m/cats\/ at /home/liblime/kohaclone/C4/Search.pm line 1319.

Apache    Server version: Apache/2.2.3 Server built: Jan 31 2008 08:42:27
Koha    3.00.00.087
Koha DB    3.0000087
MySQL    mysql Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (x86_64) using
readline 5.2
OS    Linux demo01.ec2.liblime.com 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36
SAST 2007 x86_64 GNU/Linux
Perl    5.008008



---- Additional Comments From joe.atzberger@liblime.com 2008-07-07 11:28:52
----

Darrell --

Works for me (no crash, valid results) on Koha 3.00.00.096.  

--joe



---- Additional Comments From jmf@liblime.com 2008-07-07 21:26:51 ----

Fixing this properly will require a refactor of the search API, and ultimately
a query parser. It might be best accomplished by 1. integrating SRU and CQL
support into Index Data's Pazpar2 tool, and then using that as the front-end
search API for Koha 3.2. I'm changing the Version to 3.2, and keeping it open
as a blocker.



---- Additional Comments From frederic@tamil.fr 2009-03-31 08:24:10 ----

Any progress in search refactoring direction? 

Now, a CCL/PQF search is possible, BUT on the first result page, at the bottom,
the next-previous buttons don't work at all. 



---- Additional Comments From laurence.lefaucheur@biblibre.com 2009-06-19
13:26:01 ----

Problem searching terms with ()

Test : 
searching cd in title : 96 results
searching (cd) in title : 8777 results, and in this case it is not possible to
go to other results pages than the first.
The link from page number is :
/koha/catalogue/search.pl?&offset=120&sort_by=relevance, and return to advanced
search page



---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 08:09:56 ----

\ works ok now

() is still a problem, its caused by

if ( $query =~ /(\(|\))/ ) {                                                    
        return (                                                                
            undef,              $query, $simple_query, $query_cgi,              
            $query,             $limit, $limit_cgi,    $limit_desc,             
            $stopwords_removed, 'ccl'                                           
        );                                                                      
    }    

Which causes us to bail out before $query_cgi has anything assigned to it, and
only the first operand used as the search.
I think that not trying to handle nested queries is a valid stance for 3.2.0 
That would mean that you can search on phrases containing ().

I have sent a patch for that, and will send a patch fixing the : error too.

Search.pm is slated for a total rewrite for 3.4.0, but I think that having it
working (and losing the nested queries) is ok for 3.2.0 .. galen?



---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 08:17:27 ----

Created an attachment
Patch to fix searching on ()





---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 09:08:28 ----

Created an attachment
Patch to stop : blocking searches





---- Additional Comments From nengard@gmail.com 2009-12-13 22:06:05 ----

*** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2702 has been marked
as a duplicate of this bug. ***



---- Additional Comments From colin.campbell@ptfs-europe.com 2010-01-28
14:36:34 ----

The second patch seems to have the unwelcome side effect of of breaking search
links in opac and staff e.g. when opac-search.pl id called with q=au:Name the
au:Name search fails



---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-02
09:55:07 ----

Chris Nighswonger has posted a patch referring to
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4074 to address the side
effect reported in the second patch.



---- Additional Comments From chris@bigballofwax.co.nz 2010-02-11 20:20:30 ----

This has been patched to a working extent for the 3.2 release

C4/Search.pm needs a total rewrite and is on the cards for 3.4 so shifting this
to that.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:34 UTC  ---

This bug was previously known as _bug_ 1807 at
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1807
Imported an attachment (id=370)
Imported an attachment (id=371)

Actual time not defined. Setting to 0.0
CC member jwagner@ptfs.com does not have an account here
CC member laurence.lefaucheur@biblibre.com does not have an account here
The original submitter of attachment 370 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 371 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Comment 1 Sharon Moreland 2010-07-13 20:13:20 UTC
Question mark doesn't work either.  Example, searching for the movie "Are we
there yet?" retrieves no results, but the same search without the question mark
"?" does.