Jack,
I am using this query to test from the browser and this occurs consistently
for the 5 out of the 6 servers in the cluster, but the actual API that I
use is pysolr, so from the front end its sent using pysolr.
I face the same issue in both Firefox and Google Chrome, the fact that
there is
It's interesting results...
I'm not a Unicode specialist, but Japanese query cannot match Arabic
documents if both of them correctly encoded.
I cannot recommend such use case, single field for all languages,
but maybe you should check indexed (analyzed) tokens for inspection, not
stored data.
Are
Thanks Eric for your comment,
If I do suggest by Full_name I got good result look to this result set
http://localhost:9090/solr/people/suggest?q=full_name%3A%D9%85%D8%B3%D8%B9%D9%88%D8%AFwt=jsonindent=true
the result will be
{
responseHeader:{
status:0,
QTime:3,
params:{
Dear all,
I am fresh to solr. below is my solrcloud:
zookeeper 3.4.5: 2 nodes
solr 4.10.2: 2 nodes
tomcat 1.7:2 nodes
solr index data is stored HDFS
solr configSet is managed by zookeeper.
Thanks for your suggestions Erick.
This may be one of those situations where you really have to
push back at the users and understand why they insist on these
kinds of queries. They must be very patient since it won't be
very performant. That said, I've seen this pattern; there are
certainly
