Thank you, Chris.
I notice crontabs are performed at different time in replicas(delayed for 10
minutes against its leader), and these crontabs is to reload dic files.
Therefore, the terms are slightly different between replicas.
So the maxScore shows difference.
Best,
Sling
--
View this messa
On 12/5/2013 2:27 AM, sling wrote:
> By the way, the "shards" param is running ok with the value
> "localhost:7574/solr,localhost:8983/solr" or "shard2",
> but it get an exception with only one replica "localhost:7574/solr";
>
> right:
> shards=204.lead.index.com:9090/solr/doc/,66.index.com:8080
By the way, the "shards" param is running ok with the value
"localhost:7574/solr,localhost:8983/solr" or "shard2",
but it get an exception with only one replica "localhost:7574/solr";
right:
shards=204.lead.index.com:9090/solr/doc/,66.index.com:8080/solr/doc/
wrong: shards=204.lead.index.c
: There is no default value for ptime. It is generated by users.
thank you, that rules out my previous wild guess.
: I was trying query with a function query({!boost b=dateDeboost(ptime)}
: channelid:0082 && title:abc), which leads differents results from the same
: shard(using the param: shards
Hi Raju,
Collection is a concept in solrcloud, and core is in standalone mode.
So you can create multiple cores in solr standalone mode, not collections.
--
View this message in context:
http://lucene.472066.n3.nabble.com/SolrCloud-FunctionQuery-inconsistency-tp4104346p4104888.html
Sent from th
..
Regards,
Raju Shikha
-Original Message-
From: sling [mailto:sling...@gmail.com]
Sent: 04 December 2013 08:33
To: solr-user@lucene.apache.org
Subject: Re: SolrCloud FunctionQuery inconsistency
Thanks, Chirs:
The schema is:
There is no default value for ptime. It is generated by
Thanks, Chirs:
The schema is:
There is no default value for ptime. It is generated by users.
There are 4 shards in this solrcloud, and 2 nodes in each shard.
I was trying query with a function query({!boost b=dateDeboost(ptime)}
channelid:0082 && title:abc), which leads differents results fro
: Yes, I am populating "ptime" using a default of "NOW".
:
: I only store the id, so I can't get ptime values. But from the perspective
: of business logic, ptime should not change.
if you are populating it using a *schema* default then the warning text i
pasted into my last message would defini
Thank for your reply, Chris.
Yes, I am populating "ptime" using a default of "NOW".
I only store the id, so I can't get ptime values. But from the perspective
of business logic, ptime should not change.
Strangely, the sort result is consistent now... :(
I should do more test case...
--
View t
Thanks, Erick
I mean the first id of the results is not consistent, and the maxScore is
not too.
When query, I do index docs at the same time, but they are not revelent to
this query.
The updated docs can not affect tf cals, and for idf, they should affect for
all docs, so the results should co
: However, when sort by "ptime desc", the result is consistent.
: The dateDeboost generate the time-weight from ptime, which is multiplied by
: the score.
As Erick mentioned, you haven't given us enough details to make any
educated guesses as to what problem you are seeing.
My wild, uneducated,
I'm not quite sure what you're seeing as
inconsistent, you didn't say. Is it the
maxScore? Did you index any docs
in the mean time? Even though both
show 121 docs, if you updated some
docs it might affect the score because
the terms from the old docs still affect
tf/idf calcs and thus the boosted s
12 matches
Mail list logo
