lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Lea <>
Subject Re: Usage of NoMergePolicy and its potential implications
Date Mon, 23 Jul 2012 13:46:01 GMT
I can't answer your questions, but use of lucene's document ids as
persistent ids is strongly discouraged, particularly in version 4.x
where I think it just won't work at all.  There was a related thread a
couple of weeks ago.  See Uwe's message at$1ad94960$508bdc20$
where he says "To uniquely identify documents later you *have* to use
a own key field."


On Mon, Jul 23, 2012 at 12:17 AM, snehal.chennuru
<> wrote:
> Hello Everyone,
> We have a legacy system which uses lucene 2.4.1. We have ported a small hack
> to lucene source code back then, so that the underlying lucene segment
> merger code wouldn't reuse deleted docids. This helped us use lucene docids
> as persistent dbids as well. But we want to upgrade lucene to 3.6, but it is
> near impossible to "hack" lucene now to get the same behavior.
> I checked out NoMergePolicy, and it seemed to help achieve similar behavior
> of not letting lucene reuse deleted docids. But I guess this would increase
> the number of segments in the index. Any idea how many segments we are
> talking about over here? Also, can we configure lucene to tell how many
> documents to keep in a given segment. Each lucene index in this system can
> have utmost 1M documents in them. Is there an alternative that I can
> consider?
> Thanks,
> Snehal
> --
> View this message in context:
> Sent from the Lucene - Java Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message