Trejkaz described it correctly: you must commit to make your recent
indexing changes durable on disk, and visible to a newly opened reader.
If the JVM, OS, hardware crashes, then any changes since the last commit
are lost.
Mike McCandless
http://blog.mikemccandless.com
On Fri, Jul 7, 2017 at 11
On Thu, Jul 6, 2017 at 8:28 PM, Joe Ye wrote:
> Thanks very much TX!
>
> Regarding "But the updates don't actually occur during the call", could you
> elaborate on this a bit more? So when would the actual update occur, by
> which I mean persisting to disk?
The same as any other updates - when yo
Thanks very much TX!
Regarding "But the updates don't actually occur during the call", could you
elaborate on this a bit more? So when would the actual update occur, by
which I mean persisting to disk? Is there a cache of a number of docValues
updates before committing to disk? If so, when happens
This is by design: you are able to add a doc values field to a previously
indexed document even if that document didn't originally index that doc
values field.
The update brings the doc values field into existence for that document.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Jul 4,
On Tue, 4 Jul 2017 at 22:39, Joe Ye wrote:
> Hi,
>
> I'm using Lucene core 6.6.
>
> I noticed an issue that DocValue update methods
> (indexWriter.updateNumericDocValue
> & indexWriter.updateBinaryDocValue) don't appear to throw exception or
> return any error code if the document doesn't exist.
Hi,
I'm using Lucene core 6.6.
I noticed an issue that DocValue update methods
(indexWriter.updateNumericDocValue
& indexWriter.updateBinaryDocValue) don't appear to throw exception or
return any error code if the document doesn't exist. Is this intentional? I
don't want to check the existence of
