Search mode: exact
Hello again Low
Sorry to bother you again so quickly, but I think I must be a little confused about the search_mode="exact" option ...
My assumption was that word order would be taken into account, so that with search_mode="exact” the search term “word-2 word-1” would NOT match the phrase “word-1 word-2”.
To give a specific example, a search for “mai chiang” is matching “chiang mai” when either search_mode="exact” and search_mode="all” are used, where I would have expected only the “all” option to work. After all, the EXACT PHRASE is “chiang mai”, so “mai chiang” should not be considered exactly the same even though it contains all the same words ...
So I must be misunderstanding something somewhere along the way. At the moment, basically, the parameters search_mode="all” and search_mode="exact” seem to be functioning in absolutely identical ways. In my situation they always return exactly the same set of results.
Anyway, I hope that all makes some kind of sense, and I hope you’ll be able to point out what I am failing to understand and how I might be able to address this situation.
Cheers
Replies
Low 15 Jul 2012 15:19
Hi Andrew,
The exact search mode should indeed search for the exact phrase as you point out. If you turn on the Output Profiler, you can see the query that is executed. It should (either by fulltext or fallback) include the exact phrase like that.
Now, it could happen that -- because the index filters out punctuation -- it will match "mai. Chang", if that happens somewhere in the text.
If you're up for it, you can check the actual index text of the entry where this is happening in the DB, to see if that exact match is indeed present there.
Andrew Mac 16 Jul 2012 01:27
Hi Low
Thanks for the hint, and I can now see that the issue lies with related Playa data. In the database one of the lines within the index field that goes like this:
| 15 chiang mai chiang mai | 15 chiang mai chiang mai | 15 chiang mai chiang mai |
I think the phrase "chiang mai" is doubling up because of the way Playa stores the entry (I think it might use both url_title and title, which would double the entry in this case). It's also interesting, though, that the "15 chiang mai chiang mai" is itself repeating three times ... I'm not sure why that is.
Thanks again for all your help with this!
Cheers
Andrew
Low 16 Jul 2012 06:51
Yeah, that'd do it.
Playa stores data like this: [entry_id] url_title Title
LS removes all non alphanumeric from the index, leaving your example: 15 chiang mai chiang mai.
That being there 3 times is the way LS adds weight to channel fields. For each weight (in this case 3), the content is concatenated, making the words in there appear more often, thus tricking MySQL's scoring mechanism to add importance to the field when searching for matching terms.
Andrew Mac 16 Jul 2012 07:41
Thanks for confirming my suspicions.
I really do need to search on the related Playa data, but need to avoid the problems that come with the way it stores data. So in the end I put together a bit of a workaround using Solspace Preparse to take the required content from Playa and put into a normal text input field in the main entry. If I change Low Search to use that field instead of the original Playa field the results do come back properly for the exact phrase search.
It's actually the second time in a few days I've had to resort to that kind of trick with Preparse, so if you've ever thought about doing that kind of add-on then I'd be very very interested. I would certainly trust you to come up with a top-notch product that would continue to be actively developed and improved ;-)
Oh, and your explanation about the weighting makes perfect sense too. I probably should have realised that was what was going on ...
Cheers
Andrew