Currently, wildcard queries are a bit different
Query : http://localhost:8983/solr/core1/select?fl=id&q=turpis&qf=content&debugQ...
Gives us : +(content:turpi)~0.01 ()
This is due to the analysers that deduct a word to its base form.
However
Query : http://localhost:8983/solr/core1/select?fl=id&q=turpis*&qf=content&debug...
Gives us : +(content:turpis*)~0.01 ()
We can see that this gives us a different result.
Solution?
We should add multiterm to the text analysers, or actually to any analyser where a wildcard could help with partial word matching.
How?
<fieldType name="text" class="solr.TextField" positionIncrementGap="100" >
<analyzer type="index">
// stuff here
</analyzer>
<analyzer type="query">
// stuff here
</analyzer>
<analyzer type="multiterm">
// same content here as the query
</analyzer>
</fieldType>
This will give us :
Query : http://localhost:8983/solr/core1/select?fl=id&q=turpis*&qf=content&debug...
Gives us : +(content:turpi*)~0.01 ()
Comment | File | Size | Author |
---|---|---|---|
#4 | 1879762-4.patch | 5.42 KB | Nick_vh |
Comments
Comment #1
Nick_vhComment #1.0
Nick_vhUpdated issue summary.
Comment #2
Nick_vhComment #3
PolThis is, I think, the best solution when you use a view with search_api and configure the query parse mode in the Views Query settings to "Direct query".
I'm using it now, and I'm very happy.
EDIT: No need to set the parse mode to "Direct query", it also works with the default mode "Multiple terms".
Comment #4
Nick_vhAdding a patch that adds this multiterm component.
I've tested it with solr 3.5 and it seems that solr 3.5 loads with this analyzer, even though it does not support it. Trying 3.4 also and if that does not appear to be any problem we should be ready to commit this. Solr 4 has more multitermaware components but we do not want to rely on those.,
Comment #5
PolWill try that asap !
Thanks Nick :)
Comment #6
Nick_vhCommitted. Finally