Thanks Simon and Trejkaz! You are right, we used this approach exactly for
the reasons you mentioned above. As we have to support old lucene indices,
we are not sure what approach to take.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Usage-of-NoMergePolicy-and-its
On Thu, Jul 26, 2012 at 5:38 AM, Simon Willnauer
wrote:
> you really shouldn't do that! If you use lucene as a Primary key
> generator why don't you build your own on top. Just add one layer that
> accepts the document and returns the PID and internally put it in an
> ID field. Using no merge poli
performance and low compression.
I think you should really consider fixing your app instead of hacking lucene.
simon
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Usage-of-NoMergePolicy-and-its-potential-implications-tp3996630p3996784.html
> Sent f
Thanks for the heads up Ian. I know it is highly discouraged. But, like I
said, it is a legacy application and it is very hard to go back and re-do
it.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Usage-of-NoMergePolicy-and-its-potential-implications-tp3996630p3996784
t; Snehal
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Usage-of-NoMergePolicy-and-its-potential-implications-tp3996630.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---
http://lucene.472066.n3.nabble.com/Usage-of-NoMergePolicy-and-its-potential-implications-tp3996630.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene
