Bug 27141

Summary: QueryWeightFields should be 0 on new installs since QueryAutoTruncate is 1
Product: Koha Reporter: David Cook <dcook>
Component: System AdministrationAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: gmcharlt
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9715
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description David Cook 2020-12-03 05:57:47 UTC
Since QueryAutoTruncate automatically disables QueryWeightFields, it does not make sense that both are set to 1 in "./installer/data/mysql/sysprefs.sql"

I think that we should have QueryWeightFields set to 0 for new installations.

It would even be tempting to set QueryWeightFields to 0 where QueryAutoTruncate is set to 1 on existing installs, except that someone might be (unwisely) trialling different Query* settings before/during a Koha upgrade.
Comment 1 Katrin Fischer 2020-12-06 12:51:45 UTC
I think we should do the opposite - turn QueryWeightFields on and turn QueryAutoTruncate off.

In my testing for a recent presentation I felt tihs to give much better and expected results.
Comment 2 David Cook 2020-12-06 22:14:15 UTC
(In reply to Katrin Fischer from comment #1)
> I think we should do the opposite - turn QueryWeightFields on and turn
> QueryAutoTruncate off.
> 
> In my testing for a recent presentation I felt tihs to give much better and
> expected results.

Personally, I hate the query mangling done by QueryWeightFields, but I think that you make a good point. Recently, I turned off QueryAutoTruncate and turned on QueryWeightFields to get a better search experience for a new Koha library.

(I have also been thinking about creating a QuerySimplified or QueryCCL option to get rid of all the query mangling and instead do something more simple and straightforward.)
Comment 3 Katrin Fischer 2020-12-06 22:41:22 UTC
Hm I think the "query mangling" is actually good in this case. I recently looked at the code and it does make sense to me what we are trying to do here - judging from results it also appears to work reasonably well.

Do you have a specific issue with it?
Comment 4 David Cook 2020-12-07 00:41:17 UTC
(In reply to Katrin Fischer from comment #3)
> Hm I think the "query mangling" is actually good in this case. I recently
> looked at the code and it does make sense to me what we are trying to do
> here - judging from results it also appears to work reasonably well.
> 
> Do you have a specific issue with it?

I think that it's trying to be too smart for its own good. 

From my perspective, the user should be able to build up their own query and get search results that actually reflect their query, rather than a mangled query.

That being said, I am a power user, so maybe novice users would prefer the system to think for them.

Maybe my other issues are actually about inconsistency and inefficiency in the query building in general, but... my latest buildQuery unit tests actually provide the start for improving the search code overall... maybe I'm just having a grump ;).
Comment 5 Katrin Fischer 2023-07-01 14:30:17 UTC
Do I remember wrongly that we fixed one pref killing the other? 

I wonder how we can proceed here. Happy to write a patch to change the default values if we can agree on something.
Comment 6 David Cook 2023-07-02 23:13:51 UTC
(In reply to Katrin Fischer from comment #5)
> Do I remember wrongly that we fixed one pref killing the other? 
> 
> I wonder how we can proceed here. Happy to write a patch to change the
> default values if we can agree on something.

I don't think it's fixed but I haven't verified it recently.