Hi ,all
I'm using 4.10.3, as András Péteri mentioned, i tried the Collector, and
looked into the source code. It seems that the collector i rewrite and the
default TopScoreCollector just collects the docs, but the socre and weight is
still calculated, so it didn't speed up the search. Maybe
this is the first time I come across error like this,
label already exists: Facet label: ..., prev ordinal: ...
It shows error happened at line 131 of CompactLabelToOrdinal.java
Any idea for what could go wrong? I am using Lucene 4.10.2
Thanks!
Hi,
I am trying to work around a CORS issue on my app server side by standing up a
proxy jsp in order to talk to Solr directly. It's really just a request
forwarder at this point in time. The problem is that the same query I run
through the proxy works fine through the browser, but when I run
Collector's javadoc in Lucene 4.x includes a bare minimum example which
only registers matching documents in a bitset:
https://github.com/apache/lucene-solr/blob/lucene_solr_4_10_4/lucene/core/src/java/org/apache/lucene/search/Collector.java#L85
You'll have to adapt this if you want to use it in L
What version of lucene are you using? From Lucene 5.1 you can tell queries to
not report scores, which will give you the speedup you require here.
Alan Woodward
www.flax.co.uk
On 30 Jul 2015, at 05:22, 丁儒 wrote:
>
>
> It seems that ConstantScoreQuery use the Weight and Score of the Query i
Hi Alex,
I never took joining based on multiple indices into account when creating
the global ordinal join.
I like your idea of using a multi reader to make the join think it is
running on one index. But I don't know if there are edge cases where this
might not work.
Martijn
On 21 July 2015 at 2
