Bugzilla – Full Text Bug Listing
| Summary: | Searching orion client for the keyword _selection shows false hits | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Ken Walker <ken_walker> | ||||
| Component: | Server | Assignee: | John Arthorne <john.arthorne> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, johnjbarton, libingw | ||||
| Version: | 0.3 | ||||||
| Target Milestone: | 0.4 M2 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Ken Walker
If I search for "selection" without the underscore, the results are all legitimate. I noticed that in the "_selection" query that selection.js does in fact have search results that I expected. Created attachment 208173 [details]
Ignore, wrong bug
ScreenShot of bug
Sorry wrong bug for the attachment I tried both orion.eclipse and local host with _selection and other keywords starting with "_" as well. Search engine always gives back some files that do not contain that key word. I am wondering if a word starting with "_" means something else than just literal . I even tried to escape it in the URL but still get he same result. Possible solution: 1.Instead of doing "on demand in file search", do a full round of in-file-search for all the result and kick the mismatched out. But this will give a reduced number of files in the page. 2.We are already doing staled file check when a file's time stamp is different than the one returned from the indexer. We can try to do so for all the files without checking time stamp and grey them out instead of removing out. But this will give user a wrong implication that the grey file will be gone later. Lucene processing on the query might also be munging this. I can take a look in M2. (In reply to comment #5) > Lucene processing on the query might also be munging this. I can take a look in > M2. Even so we may still want a second level hit-test in case there is a hole in Lucene. "0 matches" gives bad first impression. You can kind of simulate this second level hit-test and see performance by clicking the "expand all" action on the right of the tool bar, right after the page loads up. John, I put this depending on bug 366847. But if you think the fix will just hit the right thing and remove the irrelevant hits, please make it dup. The tokenizer on the server is discarding the leading underscore from the query, so it is just searching for "selection". If we avoid the tokenizer that removes non-alphanumeric characters, it doesn't find a match on "_selection". This is because the document actually contains the word, "this._selection". If you search for "*_selection" you will get the smaller set of results that you expect. I am thinking we should automatically add leading and trailing * to the query so that we match partial word segments. (In reply to comment #9) > If we avoid the tokenizer that removes non-alphanumeric characters, it doesn't > find a match on "_selection". This is because the document actually contains > the word, "this._selection". If you search for "*_selection" you will get the > smaller set of results that you expect. > > I am thinking we should automatically add leading and trailing * to the query > so that we match partial word segments. If we automatically add leading and trailing *, we will have to always use reg express for the "in file search" unless the URL tells us what the user originally typed in. This will significantly affect the match highlighting as the range gets wider. E.g. "fullLineRedraw = ((getStyle() & SWT.FULL_SELECTION" will be highlighted instead of "_SELCTION". Maybe we really need the original keyword as a special parameter in the search URL. (In reply to comment #10) > If we automatically add leading and trailing *, we will have to always use reg > express for the "in file search" unless the URL tells us what the user > originally typed in. I meant adding the wildcard on the server. I have tried this and it seems to work quite well. The client isn't aware of the wildcard but it doesn't need to be, since it is already doing a raw search of the file contents. I think leading/trailing wildcards shouldn't have any effect in the client's search. I have pushed a fix for this that is looking good to me... please give it a spin in the next build: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=a881e8b3c0899a91ca245a6f8d1a6d91ad7a738f Marking fixed. (In reply to comment #11) > (In reply to comment #10) > > If we automatically add leading and trailing *, we will have to always use reg > > express for the "in file search" unless the URL tells us what the user > > originally typed in. > > I meant adding the wildcard on the server. I have tried this and it seems to > work quite well. The client isn't aware of the wildcard but it doesn't need to > be, since it is already doing a raw search of the file contents. I think > leading/trailing wildcards shouldn't have any effect in the client's search. Nice. I just quickly tried it out. The best part I like is that it treats the keyword as "occurs any where" instead of "occurs as whole word". Realistically, "matching partial word segments" is very useful for me. Before this fix, it blocked me in some cases where I can't really remember the whole word of the keyword and had to try really hard. *** Bug 366755 has been marked as a duplicate of this bug. *** I just tried this again and it seems much better. I only get back 5 hits now. |