Even though I can
live without them they can be a performance boost.
Victor
From: Chris Hostetter <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Lucene 1.9.1 and timeToString() apparent incompatibility with
1.4.3
Date: Wed, 8 Mar 20
: Thanks Chris for making it clear, I had read the comment but I had not
: understood that it implied incompatibility. But will the code be preserved
: in Lucene 2.0, in light of the comment contained in the Lucene 1.9.1
: announcement ?
I don't really know, it's currently being discussed in LUCE
warnings
before they are compatible with 2.0.
UNQUOTE
Victor
From: Chris Hostetter <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Lucene 1.9.1 and timeToString() apparent incompatibility with
1.4.3
Date: Tue, 7 Mar 2006 17:54:27 -080
: timeToString() and stringToTime() classes are used. Using an index created
: with 1.4.3 and searched with 1.9.1 I now receive the following errors:
As the deprecation comment in DateField says...
If you build a new index, use DateTools instead. For existing indices
you
can co
I recently converted from Lucene 1.4.3 to 1.9.1 and in the processed
replaced all deprecated classes with the new ones as recommended (for
forward compatibility with Lucene 2.0).
This however seems to introduce an incompatibilty when the new
timeToString() and stringToTime() classes are used. Using
I recently converted from Lucene 1.4.3 to 1.9.1 and in the process replaced
all deprecated classes with the new ones as recommended (for forward
compatibility with Lucene 2.0).
This however seems to introduce an incompatibilty when the new
timeToString() and stringToTime() classes are used. Us
