Bug 27141 - QueryWeightFields should be 0 on new installs since QueryAutoTruncate is 1
Summary: QueryWeightFields should be 0 on new installs since QueryAutoTruncate is 1
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-03 05:57 UTC by David Cook
Modified: 2023-07-02 23:13 UTC (History)
1 user (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 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.