Bug 24895 - Elasticsearch CCL searching with phr modifier doesn't work
Summary: Elasticsearch CCL searching with phr modifier doesn't work
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching - Elasticsearch (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-18 15:21 UTC by Andrew Fuerste-Henry
Modified: 2021-01-18 15:40 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
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 Andrew Fuerste-Henry 2020-03-18 15:21:18 UTC
To test:
- enable DumpSearchQueryTemplate so you can easily check the contents of your query
- enter a CCL search of ti,phr:batman
- confirm the query gets processed as just ti:batman
Comment 1 Katrin Fischer 2020-03-19 07:39:49 UTC
Hi Andrew, have you tried with more than one word?
Comment 2 Katrin Fischer 2020-04-28 22:57:02 UTC
I just realized this was filed for Elasticsearch.

For Zebra, it seems all good:
'query_cgi' => 'q=ccl=ti%2Cphr%3Astreet',
'querystring' => 'ti,phr:street',
'search_query' => '(rk=( ti,phr="street")) ',

I think for Elasticsearch you are correct, it doesn't look like phrase is always used. It appears to work when Title, phrase from advanced search is used, but not when you enter the ccl = is ccl understood by Elasticsearch at all?
Comment 3 Andrew Fuerste-Henry 2020-04-29 00:56:25 UTC
Oh, and I'm sorry I completely missed your earlier question. Yes, CCL works in Elastic broadly.
This isn't a huge deal, since Elastic lets you use quotation marks. So ti:"Batman Returns" does that ti,phr:Batman Returns fails to do. But it'd still be good to maintain some continuity for longtime Zebra users.
Comment 4 Nick Clemens 2020-12-22 15:00:16 UTC
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm :
 _convert_index_strings_freeform
 781 This is similar to L<_convert_index_strings>, however it'll search out the
 782 things to change within the string. So it can handle strings such as
 783 C<(su:foo) AND (su:bar)>, converting the C<su> appropriately.
 784 
 785 If there is something of the form "su,complete-subfield" or something, the
 786 second part is stripped off as we can't yet handle that. Making it work
 787 will have to wait for a real query parser.