Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.saltiel@gmail.com
 designates 209.85.161.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=TATU/mvfVgpQwMeRuikKxtHbVjat+u5Der5hbbwydBoDik38HoxodtArIuMoA38mIh
         dJQT0WzICy8I3Ju/35iCpG3qFvfp+BqYPhLZaXSwjQ2XIhStIfaGhWCGCVgxlSxIU99b
         4deqxehgzt9Twkrgs9bOtDrzJB7D94lELYekg=
MIME-Version: 1.0
In-Reply-To: <AANLkTinayng2c4_dYinFkEcnhsXXqNDJYGSN-BxjT6SX@mail.gmail.com>
References: <tencent_016058B91870538D7A4400B4@qq.com>
	<1596394141-1293637049-cardhu_decombobulator_blackberry.rim.net-1951755217-@b15.c6.bise7.blackberry>
	<AANLkTimZpH9BnaDdgrk2K-B3cfwbbwspALsTLnOgHtxW@mail.gmail.com>
	<37455700-1293642926-cardhu_decombobulator_blackberry.rim.net-1955853008-@b15.c6.bise7.blackberry>
	<AANLkTim+enpp=Ou=19W7CFbeubJ2k+zRS5GZz5BRosrP@mail.gmail.com>
	<499C43A3-01DA-4099-AB23-D1941FCC639A@apache.org>
	<AANLkTinayng2c4_dYinFkEcnhsXXqNDJYGSN-BxjT6SX@mail.gmail.com>
Date: Tue, 4 Jan 2011 18:25:57 +0000
Message-ID: <AANLkTikDcT9-P3fgwt34zzyJA9ym_jNfWFPn_K1Af3-X@mail.gmail.com>
Subject: Re: Using Lucene to search live, being-edited documents
From: adasal <adam.saltiel@gmail.com>
To: java-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=20cf3054a56d530e7304990966fe

--20cf3054a56d530e7304990966fe
Content-Type: text/plain; charset=UTF-8

I would think this is more like it.
But the essential thing, so it seems to me, is whether there is a
requirement for a serialised index, i.e. a more permanent record, aside from
the saved document.
Then, if there is a penalty to creating the index compared to regex,
stringsearch or so, it is justified on other grounds.
I think it is an interesting q. when does that requirement emerge?
There is size of document.
But there would also be field types. I think I have this right. This is
really a classification system, so more than bare regex.
There must be other criteria that apply to this use case, too?

Adam

p.s. we (in my work project) are just beginning to use Lucene for geometry
objects and I am looking forward to understanding its use better, including,
possibly, expanding it to other use cases apart from geo objects.

On 3 January 2011 15:31, Robert Muir <rcmuir@gmail.com> wrote:

> On Mon, Jan 3, 2011 at 10:16 AM, Grant Ingersoll <gsingers@apache.org>
> wrote:
> > There is also the MemoryIndex, which is in contrib and is designed for
> one document at a time.  That being said, basic grep/regex is probably fast
> enough.
> >
>
> In cases where you are doing a 'find' in a document similar to what a
> wordprocessor would do (especially if you want to iterate
> forwards/backwards through matches etc), you might want to consider
> something like
> http://icu-project.org/apiref/icu4j/com/ibm/icu/text/StringSearch.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

--20cf3054a56d530e7304990966fe--