This is actually due to a bug:
https://issues.apache.org/jira/browse/LUCENE-3065
which was ixed in 3.2. The bug is that, prior to Lucene 3.2, if you
stored a NumericField, when you later load that document, the field is
converted to an ordinary Field (no longer numeric), so when you then
ind
My guess is that LUCENE-3065 won't help. Couldn't do the read/update
stuff before NumericFields came along and still can't, with or without
that patch.
--
Ian.
On Thu, May 10, 2012 at 9:26 AM, Tim Eck wrote:
> Thanks for the response (and sorry for the excessive duplicate posting to
> the lis
Thanks for the response (and sorry for the excessive duplicate posting to
the list, that obviously wasn't on purpose).
I should have explicitly asked this, but one specific thing I wondered was
whether LUCENE-3065 would make any difference in my example program (I
haven't had time to test it yet)
Similarity.setDefault(new MySimilarity()) is certainly better than the
2 calls I recommended. Thanks.
I find it hard to see why one might not want to do this in normal
usage but have a vague recollection of someone once outlining some
obscure scenarios where different similarities at index and se
Impossible to say - how big is big? How fast is fast? I'd start with
the simplest option and if it's fast enough, stop.
--
Ian.
On Sat, May 5, 2012 at 12:47 AM, Yang wrote:
> I have an index containing all students, now I want to do an index
> search inside an Apache Hadoop mapper,
> i.e.
>
You can't selectively update fields in docs read from an index, in old
or current versions of lucene. I think there are some ideas floating
around but nothing usable today as far as I know. You'll need to
rebuild the whole doc before passing it to writer.updateDocument().
--
Ian.
On Wed, May
