lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Using Lucene to search live, being-edited documents
Date Wed, 29 Dec 2010 17:15:25 GMT
What has this to do with Lucene? You're thinking its index would be faster than your own search
algorithm. Would it though? Do you really need an index or a good pattern matcher? I can't
see what the stream buffer being flushed by the user has to do with it? Don't you have to
control that behaviour?

Sent using BlackBerry® from Orange

-----Original Message-----
From: software visualization <>
Date: Wed, 29 Dec 2010 11:55:17 
To: <>; <>
Subject: Re: Using Lucene to search live, being-edited documents

I am writing a text editor and have to provide  a certain search
functionality .

The  use case is for single user. A single  document is potentially very
large and numerous such documents may be open and unflushed at any given
time. Think many files of an IDE, except the files are larger. The user is
free to change, say, variables names across documents which may be separate
files opened simultaneously in a variety of tabs (say)  and being edited
with no guarantee that the user has flushed or saved any of it.

On Wed, Dec 29, 2010 at 10:37 AM, <> wrote:

> This is interesting. What are we driving at here? A single user? That
> doesn't make sense to unless you want to flag certain things as they
> construct the document. Or else why don't they know what is in their own
> document? There must be other ways apart from Lucene. It seems to me you
> want each line parsed as soon as entered and matched against some criteria.
> I would look at plugins for Open Office first. Or any other text editor. But
> not sure you have given enough information.
> Sent using BlackBerry® from Orange
> -----Original Message-----
> From: "Sean" <>
> Date: Wed, 29 Dec 2010 15:35:17
> To: java-user<>
> Reply-To:
> Subject: Re:Using Lucene to search live, being-edited documents
> Does it make any sense?
>  Every time a search result is shown, the original document could have been
> changed,  no matter how fast the indexing speed is.
> If you can accept this inconsistency, you do not need to index so
> frequently at all.
> ------------------ Original ------------------
> From:  "software visualization"<>;
> Date:  Wed, Dec 29, 2010 06:06 AM
> To:  "java-user"<>;
> Subject:  Using Lucene to search live, being-edited documents
> This has probably been asked before but I couldn't find it, so...
> Is it possible / advisable / practical to use Lucene as the  basis of a
> live
> document search capability? By "live document" I mean a largish document
> such as a word processor might be able to handle which is being edited
> currently. Examples would be Word documents of some size that are begin
> written, really huge Java files, etc.
> The user is sitting there typing away and of course everything is changing
> in real time. This seems to be orthogonal to the idea of a Lucene index
> which is costly to construct  and costly to update.

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