Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Daniel Noll <daniel@nuix.com>
Organization: Nuix Pty Ltd
To: java-user@lucene.apache.org
Subject: Re: Document ID shuffling under 2.3.x (on merge?)
Date: Wed, 12 Mar 2008 12:26:51 +1100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
References: <200803111645.27956.daniel@nuix.com>
 <200803120839.19906.daniel@nuix.com>
 <359a92830803111553y60847045o2ab2ec895e02b497@mail.gmail.com>
In-Reply-To: <359a92830803111553y60847045o2ab2ec895e02b497@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200803121226.51420.daniel@nuix.com>

On Wednesday 12 March 2008 09:53:58 Erick Erickson wrote:
> But to me, it always seems...er...fraught to even *think* about relying
> on doc ids. I know you've been around the block with Lucene, but do you
> have a compelling reason to use the doc ID and not your own unique ID?

=46rom memory it was around a factor of 10 times slower to use a text field=
 for=20
this; I haven't tested it recently and the case of retrieving the Document=
=20
should be slightly faster now that we have FieldSelector, but it certainly=
=20
won't be faster as to get the document you need the ID in the first place.

=46or single documents it wasn't a problem, the use cases are:
  1. Bulk database operations based on the matched documents.
  2. Creating a filter BitSet based on a database query.

Effectively this is required because Lucene offered no way to update a=20
Document after it was indexed; if it had that feature we would never have=20
needed a database. ;-)

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org