bq: But can I assume that docids in other segments (other than the last one) will be relatively stable?
Kinda. Maybe. Maybe not. It depends on how you define "other than the last one". The key is that the internal doc IDs may change when segments are merged. And old segments get merged. Doc IDs will _never_ change in a segment once it's closed (although as you note they may be marked as deleted). But that segment may be written to a new segment when merging and the internal ID for a given document in the new segment bears no relationship to internal ID in the old segment. BTW, I think you only really care when opening a new searchers. There is a UserCache (see solrconfig.xml) that gets notified when a new searcher is being opened to give it an opportunity to refresh itself, is that useful? As long as a searcher is open, it's guaranteed that nothing is changing. Hard commits with openSearcher=false don't open new searchers, which is why changes aren't visible until a softCommit or a hard commit with openSearcher=true despite the fact that the segments are closed. FWIW, Erick Best Erick On Sat, Nov 23, 2013 at 12:40 AM, Roman Chyla <roman.ch...@gmail.com> wrote: > Hi, > docids are 'ephemeral', but i'd still like to build a search cache with > them (they allow for the fastest joins). > > i'm seeing docids keep changing with updates (especially, in the last index > segment) - as per > https://issues.apache.org/jira/browse/LUCENE-2897 > > That would be fine, because i could build the cache from diff (of index > state) + reading the latest index segment in its entirety. But can I assume > that docids in other segments (other than the last one) will be relatively > stable? (ie. when an old doc is deleted, the docid is marked as removed; > update doc = delete old & create a new docid)? > > thanks > > roman >
