TermDocs

2010-05-12 Thread roy-lucene-user
Hi guys, I've had this code for some time but am just now questioning if it works. I have a custom filter that i've been using since Lucene 1.4 to Lucene 2.2.0 and it essentially builds up a BitSet like so: for ( int x = 0; x < fields.length; x++ ) { for ( int y = 0; y < values.length; y++

Re: getting started

2008-08-01 Thread roy-lucene-user
That certainly works if the intent is to grab the entire file. If all you want is that particular line to be returned in the search then that's not going to work. Let's say the files was made up of a million lines and the text was stored in the index (I know, absurd). When grabbing the Document

Re: getting started

2008-08-01 Thread roy-lucene-user
Hello Brittany, I think the easiest thing for you to do is make each line a Document. You might want a FileName and LineNumber field on top of a "Text" field, this way if you need to gather all the lines of your File back together again you can do a search on the FileName. So in your case: Docu

Re: Lucene faster on JDK 1.5?

2005-07-08 Thread roy-lucene-user
This might be a good time to ask another question. Are there any advantages to lucene using the java.nio package? Roy On 7/8/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > > > Nothing significant, but I've been using 1.5 on > Simpy.com(lots of > Lucene behind it) for over

Re: new added documents not showing

2005-03-23 Thread roy-lucene-user
Pasha, in short, that is all I'm trying to do. Wasn't an issue really before. Otis, not sure what Luke is. But the documents appear after we optimize. Roy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e

Re: new added documents not showing

2005-03-22 Thread roy-lucene-user
Pasha, in short, that is all I'm trying to do. Wasn't an issue really before. Otis, not sure what Luke is. But the documents appear after we optimize. Roy. On Mon, 21 Mar 2005 18:20:32 -0800 (PST), Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > * Replies will be sent through Spamex to java-use

Re: new added documents not showing

2005-03-21 Thread roy-lucene-user
correct, we also can't see the new documents when we open an IndexReader to the main index. Roy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: new added documents not showing

2005-03-21 Thread roy-lucene-user
> When do you open the index writer? Where is the code? Ah, sorry. That last section is in a method that gets called in a loop. IndexWriter writer = null; try { writer = new IndexWriter( mainindex, new StandardAnalyzer(), false ); for ( int i = 0; i < dir

Re: new added documents not showing

2005-03-21 Thread roy-lucene-user
On Sat, 19 Mar 2005 22:43:44 +0300, Pasha Bizhan <[EMAIL PROTECTED]> wrote: > Could you provide the code snippets for your process? > Sure (thanx for helping, btw) I just realized that the way I described our process was off a little bit. Here's the process again: 1. grab all index Directorys

Re: new added documents not showing

2005-03-18 Thread roy-lucene-user
Hi guys, Just trying to understand where problems can occur. Maybe I need to describe our indexing process some more. We create new indexes as "index parts" with Documents that are supposed to contain unique ID key fields. These "index parts" get merged into two separate indexes: a main index

Re: new added documents not showing

2005-03-18 Thread roy-lucene-user
> > However, after optimizing, suddenly those new documents > > appear. Its almost as if the new segments are not being read > > by the IndexReader. > > You need to close IndexWriter before open IndexReader. Or reopen > IndexReader. > > See TestIndexReader.java:: private void deleteReaderWriterC

new added documents not showing

2005-03-17 Thread roy-lucene-user
Hi guys, We were noticing some odd behavior recently with our indexes. We have a process that adds new documents into our indexes. When we iterate through all the documents through an IndexReader, we're not seeing the new documents and we're not seeing the new documents when we run a search.