Two points about Analyzers:
Does anyone have any experience with thread safety of Analyzer implementations.
Apart from PerFieldAnalyzerWrapper, the analyzers seem to be thread safe, but
is there a requirement that analyzers should be thread safe?
Secondly, has anyone thought that it would
On 11/24/06, Antony Bowesman [EMAIL PROTECTED] wrote:
Two points about Analyzers:
Does anyone have any experience with thread safety of Analyzer implementations.
Apart from PerFieldAnalyzerWrapper, the analyzers seem to be thread safe, but
is there a requirement that analyzers should be
I was going to write this (+ diff below):
It looks like we have duplicate MoreLikeThis.java in contrib. Which one
would you like to keep, Mark (Harwood)?
But then I looked at contrib/similarity and saw that most/all of its content
has been moved to contrib/queries. Should we remove
I believe they are the same but the one to keep is in contrib/queries.
The queries directory was suggested as a better location for
organising contrib code - see here:
http://www.gossamer-threads.com/lists/lucene/java-dev/32872#32872
I chose to copy MoreLikeThis to contrib/queries and not
[
http://issues.apache.org/jira/browse/LUCENE-721?page=comments#action_12452544 ]
Grant Ingersoll commented on LUCENE-721:
Care to update this for Clover, Michael? Then I can hook it into the site and
the nightly builds.
Thanks,
Grant
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452545 ]
Grant Ingersoll commented on LUCENE-707:
The other projects are listed under others. I pretty much copied SOLR's layout
and then moved Lucene Java XDocs
[
http://issues.apache.org/jira/browse/LUCENE-721?page=comments#action_12452553 ]
Michael Busch commented on LUCENE-721:
--
Sure Grant, I will update the patch soon to use clover instead of EMMA. Great
that you will add it to the website!
[ http://issues.apache.org/jira/browse/LUCENE-721?page=all ]
Michael Busch reassigned LUCENE-721:
Assignee: Michael Busch
Code coverage reports
-
Key: LUCENE-721
URL:
Hi,
Could we make Hits non-final, or at least expose something in Hits to control
the number of Documents it reads from disk?
I'm looking at:
getMoreDocs(50); // retrieve 100 initially
...
int n = min * 2;// double # retrieved
(Why * 2? To read and cache ahead?)
... and wondering how I
Hi,
Poking around Query/Weight/Scorer classes I finally started understanding how
some portions of the scoring works (imagine a lot of lightbulbs now). In one
of my Lucene use-cases I really just use it to pull N documents from an index,
and don't care for score (I sort by time). That lead
On Nov 24, 2006, at 10:38 PM, Otis Gospodnetic wrote:
Could we make Hits non-final, or at least expose something in Hits
to control the number of Documents it reads from disk?
I'm looking at:
getMoreDocs(50); // retrieve 100 initially
...
int n = min * 2;// double # retrieved
(Why *
11 matches
Mail list logo
