Hi Erick, Many thanks for the info. An additional question: Do i understand you correctly that when two segmets get merged, the docids (of the original segments) remain the same?
(unless, perhaps in situation, they were merged using the last index segment which was opened for writing and where the docids could have suddenly changed in a commit just before the merge) Yes, you guessed right that I am putting my code into the custom cache - so it gets notified on index changes. I don't know yet how, but I think I can find the way to the current active, opened (last) index segment. Which is actively updated (as opposed to just being merged) -- so my definition of 'not last ones' is: where docids don't change. I'd be grateful if someone could spot any problem with such assumption. roman On Sat, Nov 23, 2013 at 7:39 PM, Erick Erickson <erickerick...@gmail.com>wrote: > 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 > > >
