Examine: multiple results and determining which field matched
I'm implementing a more complicated search function, and I have two questions that I'm hoping the Examine/Lucene gurus can answer.
First, if the search is across multiple fields, does Examine indicate which of fields in the returned results contains the match? I'd like, if possible, to display a snippet of the actual match rather than a standard field.
Second, in Lucene you can store multiple values against the same field - does this work when using the Examine interface?
The reason I ask is that the client has requested an autocomplete function on the search box driven off a keywords field in umbraco. I need to take the search term typed in and return a list of possible keyword matches. I was thinking that I either need to create a separate index for the node/keyword pairs OR to split the keywords on their way to the index (via an event) and push them all as multiple values for the same field.
However, I'm not sure if I can have multiple items with the same node ID, or whether multiple values for a field will work, or whether I can determine which keyword matched when I do get a result.
I hope the above makes sense, I'm happy to provide any required clarification...
No, Examine doesn't expose any way to find the matched fields, there's no performant way in Lucene to achieve that.
Lucene does allow you to store multiple values against a single field in the document but it's not something that's exposed in Examine, it's too much of an edge case to expose that. You could probably do it with the DocumentWriting event, as that exposes the Lucene document, but it'd be something custom you'd have to code up.
@slace it's a real bummer that there isn't a good way to find which item contains the match - it makes it a bit tricky when trying to show a relevant snippet to the user. You wouldn't recommend the Highlight contrib work?
So if I wanted to index using multiple values, apart from using the DocumentWriting event on the indexing, I'd probably have to use a Lucene search rather than Examine when retrieving it. If I went down this increasingly convoluted path at all, that is.
I have another question, but I'll pose it in a separate thread to avoid cluttering this one up. I've marked slace's answer as the solution, but both responses were helpful so thanks.
Oh sorry, I thought you were referring to the field that matched it (ie - was it nodeName, bodyText, etc). Yes if that's what you mean look into the contrib project for Lucene. I haven't used any of them myself though.
For retrieving data in a customized index you'd need to write your own provider, I don't believe there are any events that fire which would be useful in that regard.
There are two parts really - first find which field was matched and then run the highlighter on it. It sounds like the first isn't really possible which is a bummer. Was the 'non-performant' method you were referring to using the IndexReader.TermPositions() method? I can see why that would be troublesome, performance wise.
Examine: multiple results and determining which field matched
I'm implementing a more complicated search function, and I have two questions that I'm hoping the Examine/Lucene gurus can answer.
First, if the search is across multiple fields, does Examine indicate which of fields in the returned results contains the match? I'd like, if possible, to display a snippet of the actual match rather than a standard field.
Second, in Lucene you can store multiple values against the same field - does this work when using the Examine interface?
The reason I ask is that the client has requested an autocomplete function on the search box driven off a keywords field in umbraco. I need to take the search term typed in and return a list of possible keyword matches. I was thinking that I either need to create a separate index for the node/keyword pairs OR to split the keywords on their way to the index (via an event) and push them all as multiple values for the same field.
However, I'm not sure if I can have multiple items with the same node ID, or whether multiple values for a field will work, or whether I can determine which keyword matched when I do get a result.
I hope the above makes sense, I'm happy to provide any required clarification...
Thanks,
JT
No, Examine doesn't expose any way to find the matched fields, there's no performant way in Lucene to achieve that.
Lucene does allow you to store multiple values against a single field in the document but it's not something that's exposed in Examine, it's too much of an edge case to expose that. You could probably do it with the DocumentWriting event, as that exposes the Lucene document, but it'd be something custom you'd have to code up.
You have full access to the lucene Document that is written in the DocumentWriting event so you can put whatever you want in there.
For your autocomplete, you can use the Lucene API to return the Top Docs in your Keyword field.
Thanks to the two Examine gurus for answering!
@slace it's a real bummer that there isn't a good way to find which item contains the match - it makes it a bit tricky when trying to show a relevant snippet to the user. You wouldn't recommend the Highlight contrib work?
So if I wanted to index using multiple values, apart from using the DocumentWriting event on the indexing, I'd probably have to use a Lucene search rather than Examine when retrieving it. If I went down this increasingly convoluted path at all, that is.
I have another question, but I'll pose it in a separate thread to avoid cluttering this one up. I've marked slace's answer as the solution, but both responses were helpful so thanks.
Oh sorry, I thought you were referring to the field that matched it (ie - was it nodeName, bodyText, etc). Yes if that's what you mean look into the contrib project for Lucene. I haven't used any of them myself though.
For retrieving data in a customized index you'd need to write your own provider, I don't believe there are any events that fire which would be useful in that regard.
There are two parts really - first find which field was matched and then run the highlighter on it. It sounds like the first isn't really possible which is a bummer. Was the 'non-performant' method you were referring to using the IndexReader.TermPositions() method? I can see why that would be troublesome, performance wise.
is working on a reply...