I actually think that the main reason for interning the field names in
Lucene is for comparison purposes and not to guarantee uniqueness (though
you get both). You will see many places in the Lucene's code where the field
name is compared using != operator instead of equals.
BTW, in your patch abo
My findings from the hprof results which showed 80% of the CPU time being in
String.intern() led me to do some reading about String.intern() and what I
found surprised me.
First, there are some very strong feelings about String.intern() and its value.
First, is this guy
(http://www.codeinstruc
Hi Pulkit,
In case you are using the standard contrib query parser (equivalent to
lucence QP), you may want to create a QueryNodeProcessor, that will convert
TermQueryNodes to WildcardQueryNodes, and attach it to the processor
pipeline:
StandardQueryParser qp = new StandardQueryParser();
((QueryN
I'm not sure what you're trying to do, but it seems to me that your best bet
is to rewrite the query returned from the QueryParser. Just traverse the
BooleanQuery clauses, converting any TermQuery to a WildcardQuery. You can
then have control over what transformation exactly you want to perform.
I
On Fri, Nov 19, 2010 at 5:06 AM, Thomas Rewig wrote:
> Hi.
>>>
>>> If I set
>>> writer.setUseCompoundFile(false);
>>> than I see a short time the 35 handles and than it drops to zero.
>>
>> Hmm what's happening during that short time? Do you have a reader open?
>>
> Yes after a commit has been i
Hi.
If I set
writer.setUseCompoundFile(false);
than I see a short time the 35 handles and than it drops to zero.
Hmm what's happening during that short time? Do you have a reader open?
Yes after a commit has been initiated, a short time a reader is still
open and that's ok. This behavior is
