Lance, Umesh thank you.
Lance I will look into this and report results when I try it out. Thank you
very much!
Umesh: Just thinking along these lines, when a user saves the document,
that event may have a semantic meaning that developers aren't privy to.
The user might be experimenting with th
Nopes. It won't be the case always. Users will not be always editing
the document. They will edit the document, then save which will be
persisted in db. You can use db triggers to push it into a indexing
queue, from which indexer can regularly pick up the document for
indexing. You can schedule you
There's a feature in lucene called an "instantiated" index. This has
all of the Lucene data structures directly as objects instead of
serialized to disk or a RAMDirectory. It never needs to be committed:
you index a document and it is immediately searchable. It is larger
and faster than a normal in
If I understand you correctly, I think that this :
If T2 < T1, Skip the result.
will always be the case. The live being edited document is always "later"
in time than the indexed information about it.
On Fri, Jan 21, 2011 at 9:11 PM, Umesh Prasad wrote:
> Hi,
> One work around would be to
Hi,
One work around would be to version the documents and store the
version as well as the timestamp of indexed document into the index.
Reading between lines I assume that
Document is
a) stored in some DB/File :
b) indexed in lucene index
User Search On on b)
Document ids
but documents are d
Hi sorry for the long delay.
The idea is that a single user is editing a single document. As they edit,
any indexes built against the document become stale, actually wrong.
Example: references to specific localities within this document are all
instantly wrong the first time a user types a new be
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 justi
On Mon, Jan 3, 2011 at 10:16 AM, Grant Ingersoll 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
wordpr
---Original Message-
>> From: software visualization
>> Date: Wed, 29 Dec 2010 11:55:17
>> To: ;
>> Reply-To: softwarevisualizat...@gmail.com
>> Subject: Re: Using Lucene to search live, being-edited documents
>>
>> I am writing a text editor
ry® from Orange
>
> -Original Message-
> From: software visualization
> Date: Wed, 29 Dec 2010 11:55:17
> To: ;
> Reply-To: softwarevisualizat...@gmail.com
> Subject: Re: Using Lucene to search live, being-edited documents
>
> I am writing a text editor and have to p
to control that behaviour?
Sent using BlackBerry® from Orange
-Original Message-
From: software visualization
Date: Wed, 29 Dec 2010 11:55:17
To: ;
Reply-To: softwarevisualizat...@gmail.com
Subject: Re: Using Lucene to search live, being-edited documents
I am writing a text editor and hav
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: &q
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
> yes, but if they are typing away, they likely aren't also searching at
> the same time unless they have two keyboards and four hands... so why
> update anything in real time?
Presumably the OP meant user-A was editing the doc and other Users ,
or a monitoring app, are searching said doc simulta
Hi Umesh,
I'm not really confident that Zoie or anything built on the current version
of Lucene would be able to handle search as you type kind of a setup.
--
Anshum Gupta
http://ai-cafe.blogspot.com
On Wed, Dec 29, 2010 at 10:39 AM, Umesh Prasad wrote:
> You can also look at Zoie and see if i
You can also look at Zoie and see if it fits your needs. This is a
contribution by linkedin.
http://snaprojects.jira.com/wiki/display/ZOIE/Home
Also look at MemoryIndex .. This is good for creating single document index
and searching on it.
http://lucene.apache.org/java/3_0_3/api/all/org/apache
On Tue, Dec 28, 2010 at 5:06 PM, software visualization
wrote:
> 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.
>
yes, but if they are typing
Hi,
An update on each word/character typed is not a practical thing to do for
lucene (as per the current scheme of things). Though there's something
called the Real Time search, which lets you search on an updated document,
though the assumption is that the frequency is not as that of a word type.
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.
19 matches
Mail list logo
