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-potent
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
On Mon, Jul 23, 2012 at 7:00 PM, snehal.chennuru wrote:
> 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.
you really shouldn't do that! If you use lucene as a Primary key
generator why don'
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.h
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
http://mail-archives.apache.org/mod_mbox/lucene-ja
