lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Woodward <a...@flax.co.uk>
Subject Re: MultiReader docid reliability
Date Fri, 30 May 2014 08:26:17 GMT
Hi Nicola,

1) A session here means as long as you have that MultiReader open.  IndexReaders see a snapshot
of the index and so document ids shouldn't change over the lifetime of an IndexReader, even
if the index is being updated.

2) MultiReader just takes an array of subindexes, so as long as the subindexes are passed
to the MultiReader constructor in the same order on both machines, the docBase assigned to
each reader context should be the same.

Alan Woodward
www.flax.co.uk


On 29 May 2014, at 14:29, Nicola Buso wrote:

> Hi,
> 
> from the javadocs:
> 
> ----
> For efficiency, in this API documents are often referred to via document
> numbers, non-negative integers which each name a unique document in the
> index. These document numbers are ephemeral -- they may change as
> documents are added to and deleted from an index. Clients should thus
> not rely on a given document having the same number between sessions. 
> ----
> 
> What does it mean in this context "sessions"? Are search sessions?
> 
> 1) If I have an index that does not change (no deletes or updates) and
> I'm keeping the MultiReader open, can the docid change executing more
> times the same search on that reader?
> 
> 2) Opening the same set of indexes in a MultiReader on different
> machines will assign different docids to the same document at runtime or
> the algorithm to calculate such docids in some way can guarantee that
> static indexes will have the same docids in different machines (than
> separated JVMs)?
> 
> 
> nicola.
> 
> 
> 
> -- 
> Nicola Buso <nbuso@ebi.ac.uk>
> EMBL-EBI
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message