Which query parser are you using, and what is the config of your search
handler? I suspect that there is some implicit phrase slop (ps) going on..
Jan
> 1. jul. 2021 kl. 17:10 skrev Mónica Marrero :
>
> Hi,
>
> I am using Solr 7.7 in Cloud with the default query parser and similarity
> algorit
Dear SOLR users,
I tried to use the following json request in python:
json={
"params":{
"q": 'Roy',
"defType": 'edismax',
"qf":'name_suggest brand_suggest',
}
}
requests.post(COLLECTION + '/autocomplete', json=json).json()
The result was inline with my expectations
Hi all,
it was completely my fault, I forgot about the elevation and that was the
reason why in one of the queries I had a different number of results. We
can see that also in the debug mode because then we have a ConstantScore.
Thank you so much for your answers and sorry for wasting your time.
the solrclients are thread safe so, yes, I recommend to use a single
instance during all the life of your application (as said I prefer have an
instance for each index/collection)
If a network problem occurs, the client will manage to reconnect
automatically to the server.
But regarding the default
Hi, Solr users
I have a oom issue in SolrIndexSearcher.buildTopDocsCollector in Solr7.7.2, I
can see the stack is from below:
at
org.apache.lucene.search.FieldComparator$LongComparator.(FieldComparator.java:359)
~[?:?] at org.apache.lucene.search.SortField.getComparator(SortField.java:354)
~[
After some research, it appears the following approach may help in this
situation and relieve the requirement of collocating indexes for Joins. It
appears one drawback maybe the types of fields supported for the JOIN field.
https://solr.apache.org/guide/8_8/other-parsers.html#cross-collection-joi
