View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 970 | Composr | search | public | 2013-01-09 07:55 | 2014-08-11 13:40 |
| Reporter | Lhasadreams | Assigned To | Chris Graham | ||
| Priority | normal | Severity | minor | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 970: Better support for negated search results | ||||
| Description | Hi, If you do a search like +brake +pipe -2010 -stand and check the box "Find exact matches (boolean search, may be slow)" Then search still returns results with the words 2010 and stand in the titles, however it respects the search parameters for the contents. If you tick the search titles only box then it behaves as expected. Cheers Ade | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 30 | ||||
| Sponsorship open | |||||
| related to | 1036 | Resolved | Chris Graham | Localise translate table |
|
|
This is really tricky. The search engine has to query MySQL separately against each field, because MySQL is not capable of efficiently running against all fields in a single query (not where our internationalised/Comcode text is concerned). So it is returning results because one of the fields, in isolation, matches the condition. We could try and solve it by 3 mechanisms: 1) Create a separate combined text index, separate to main fields 2) Make internationalisation optional 3) Do a set operation to subtract any positive search results for the requested negative criteria All these would be very labour intensive, so I think it is best just to state that the filter works on each individual field. |
|
|
This will now work if multi-lang-content has been disabled. However I should note there is still a case that cannot be handled... If you declare two forced-positive match terms, and they apply, but not all to any single field together, it can't get a match. E.g. +foo +bar would not match if something had a title of "some foo" and content of "some bar". But it would match if the content was "some foo bar". This is due to the matching working on individual fields. The overall logic is now combined, with negatives hitting one field disallowing any other fields from matching - but it still operates on individual fields at heart. This probably is not something many people will ever notice, as it is unlikely a title will be the only place a forced-positive match term will appear. |
|
|
Actually, remove the above caveat - I believe I can workaround that. |
