On Mon, Nov 25, 2013 at 12:54 AM, Mikhail Khludnev < mkhlud...@griddynamics.com> wrote:
> Roman, > > I don't fully understand your question. After segment is flushed it's never > changed, hence segment-local docids are always the same. Due to merge > segment can gone, its' docs become new ones in another segment. This is > true for 'global' (Solr-style) docnums, which can flip after merge is > happened in the middle of the segments' chain. > As well you are saying about segmented cache I can propose you to look at > CachingWrapperFilter and NoOpRegenerator as a pattern for such data > structures. > Thanks Mikhail, the CWF confirms that the idea of regenerating just part of the cache is doable. The CacheRegenerators, on the other hand, make no sense to me - and they are not given any 'signals', so they don't know if they are in the middle of some regeneration or not, and they should not keep a state (of previous index) - as they can be shared by threads that build the cache Best, roman > > > On Sat, Nov 23, 2013 at 9: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 > > > > > > -- > Sincerely yours > Mikhail Khludnev > Principal Engineer, > Grid Dynamics > > <http://www.griddynamics.com> > <mkhlud...@griddynamics.com> >
