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, <[email protected]> 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 <[email protected]> > Date: Wed, 29 Dec 2010 11:55:17 > To: <[email protected]>; <[email protected]> > Reply-To: [email protected] > 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, <[email protected]> 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" <[email protected]> >> Date: Wed, 29 Dec 2010 15:35:17 >> To: java-user<[email protected]> >> Reply-To: [email protected] >> 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"<[email protected]>; >> Date: Wed, Dec 29, 2010 06:06 AM >> To: "java-user"<[email protected]>; >> >> 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 [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
