Check out the Instantiated contrib for Lucene. This is an alternative in-memory data structure that does not need commits and is faster (and larger) than the Lucene Directory system.
On Wed, Dec 29, 2010 at 9:15 AM, <adam.salt...@gmail.com> wrote: > 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 <softwarevisualizat...@gmail.com> > Date: Wed, 29 Dec 2010 11:55:17 > To: <java-user@lucene.apache.org>; <adam.salt...@gmail.com> > Reply-To: softwarevisualizat...@gmail.com > 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, <adam.salt...@gmail.com> 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" <spaceh...@foxmail.com> >> Date: Wed, 29 Dec 2010 15:35:17 >> To: java-user<java-user@lucene.apache.org> >> Reply-To: java-user@lucene.apache.org >> 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"<softwarevisualizat...@gmail.com>; >> Date: Wed, Dec 29, 2010 06:06 AM >> To: "java-user"<java-user@lucene.apache.org>; >> >> 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. >> >> TIA >> > > -- Lance Norskog goks...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
