Return-Path: 
 <java-user-return-58448-apmail-lucene-java-user-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-java-user-archive@www.apache.org
Delivered-To: apmail-lucene-java-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8344E10992
	for <apmail-lucene-java-user-archive@www.apache.org>;
 Fri, 30 May 2014 10:05:47 +0000 (UTC)
Received: (qmail 18008 invoked by uid 500); 30 May 2014 10:05:45 -0000
Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org
Received: (qmail 17943 invoked by uid 500); 30 May 2014 10:05:45 -0000
Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:java-user-help@lucene.apache.org>
List-Unsubscribe: <mailto:java-user-unsubscribe@lucene.apache.org>
List-Post: <mailto:java-user@lucene.apache.org>
List-Id: <java-user.lucene.apache.org>
Reply-To: java-user@lucene.apache.org
Delivered-To: mailing list java-user@lucene.apache.org
Received: (qmail 17935 invoked by uid 99); 30 May 2014 10:05:45 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2014 10:05:45 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from [74.125.82.45] (HELO mail-wg0-f45.google.com) (74.125.82.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2014 10:05:42 +0000
Received: by mail-wg0-f45.google.com with SMTP id m15so1747749wgh.16
        for <java-user@lucene.apache.org>;
 Fri, 30 May 2014 03:05:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:mime-version:content-type:from
         :in-reply-to:date:cc:message-id:references:to;
        bh=/3dl6utd4ioFvDMjBi2kARc9LR++wdbJvAzrA/pxf6E=;
        b=aHa6MnSLMDvlwMpnEsMfTyBITxJs6oZqDr5MmTgSUfbdtuBpFJKhwsplUqpxSfJIWB
         11tWHura5qwATffISXIDn0dilqpeJEBlfKorJoCS0iYf7kQcw73usmfOimUluKaImJrK
         bVsKBNWcg7nYCeRdCaelXUCtp/uVyFH+8WBL1LfsGJWTQ6QvyXJLnBppQ5prkDz+wnkO
         ePV2Q5omQPdur01tCpikHx9heN6z/QZWi9iwc/vZ8Hd1trrVGgbDRzr7sfIxu0zRyGQq
         K7cUVVyvqLQn4cQmuZkxUF5doYLWgCB2u8Pz5aHnzuc5XLzVDWAHCCUV2oj6mCn10L6/
         WN1g==
X-Gm-Message-State: 
 ALoCoQnC17AlZwFDp99WuhL+S47ZGe6wlmNDBlhVIadwZIB5sRV6dM2dqM2pB2lJ09r49xJcVhBO
X-Received: by 10.194.5.5 with SMTP id o5mr20519021wjo.16.1401444318516;
        Fri, 30 May 2014 03:05:18 -0700 (PDT)
Received: from [192.168.0.2] (80-44-234-192.dynamic.dsl.as9105.com.
 [80.44.234.192])
        by mx.google.com with ESMTPSA id l9sm4635740wic.21.2014.05.30.03.05.15
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Fri, 30 May 2014 03:05:16 -0700 (PDT)
Subject: Re: MultiReader docid reliability
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_4253CB3F-573F-4D8C-A5E8-E02F000BCA46"
From: Alan Woodward <alan@flax.co.uk>
In-Reply-To: <1401442746.2314.82.camel@linuxf.windows.ebi.ac.uk>
Date: Fri, 30 May 2014 11:05:13 +0100
Cc: java-user@lucene.apache.org
Message-Id: <10E9535F-DEAA-495B-8F65-EAFB65FE4C91@flax.co.uk>
References: <1401370158.2314.60.camel@linuxf.windows.ebi.ac.uk>
 <A4591199-CF37-4182-817E-4B7D44186A49@flax.co.uk>
 <1401442746.2314.82.camel@linuxf.windows.ebi.ac.uk>
To: nbuso@ebi.ac.uk
X-Mailer: Apple Mail (2.1283)
X-Virus-Checked: Checked by ClamAV on apache.org

--Apple-Mail=_4253CB3F-573F-4D8C-A5E8-E02F000BCA46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

If the index is truly unchanging (ie there's no IndexWriter open on it) =
then I guess the document numbers will be stable across reopens.  But =
this is a pretty specialized situation, and the docs are really there to =
warn you off trying to rely on this for more typical uses.

Alan Woodward
www.flax.co.uk


On 30 May 2014, at 10:39, Nicola Buso wrote:

> Hi Alan,
>=20
> thanks a lot for the reply.
>=20
> For what I understood from your reply if the index is not changing (no
> adds, deletes even updates) the docs id viewed by the MultiReader will
> not change if you open more times that unchanged index also in =
different
> environments.
>=20
> If this is true (my understanding) the word "ephemeral" in the API =
could
> be elaborated a bit more.
>=20
>=20
> nicola
>=20
> On Fri, 2014-05-30 at 09:26 +0100, Alan Woodward wrote:
>> Hi Nicola,
>>=20
>>=20
>> 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.
>>=20
>>=20
>> 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.
>>=20
>> Alan Woodward
>> www.flax.co.uk
>>=20
>>=20
>>=20
>> On 29 May 2014, at 14:29, Nicola Buso wrote:
>>=20
>>> Hi,
>>>=20
>>> from the javadocs:
>>>=20
>>> ----
>>> 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.=20
>>> ----
>>>=20
>>> What does it mean in this context "sessions"? Are search sessions?
>>>=20
>>> 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?
>>>=20
>>> 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)?
>>>=20
>>>=20
>>> nicola.
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Nicola Buso <nbuso@ebi.ac.uk>
>>> EMBL-EBI
>>>=20
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>=20
>>>=20
>>=20
>>=20
>=20
> --=20
> Nicola Buso <nbuso@ebi.ac.uk>
> EMBL-EBI
>=20


--Apple-Mail=_4253CB3F-573F-4D8C-A5E8-E02F000BCA46--