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:58 AM, Trejkaz <trej...@trypticon.org> wrote: > On Thu, Jul 6, 2017 at 8:28 PM, Joe Ye <yuanzhou...@gmail.com> 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 you call commit(). > > > Is there a cache of a number of docValues updates before committing to > disk? > > Someone who knows the internals better would probably have to answer > this one. I don't know how merging of updates to doc values works. (I > am guessing the doc values generation come into play here?) But > flushing to disk and committing changes are two different things > anyway. Lucene will periodically flush changes to disk when it decides > that it can't keep more in memory, This is not the same as it actually > committing, which makes the changes visible to newly-opened readers. > You just end up with files on disk which aren't referenced from the > segments file yet. > > > If so, when happens if a crash occurs before those updates are committed? > > Hopefully none of the updates occur, but the science hasn't been done. > (It seems like a fairly easy experiment to do if you really want to > test it.) > > TX > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
