[jira] Created: (LUCENE-537) Refactor of spell check

Refactor of spell check --- Key: LUCENE-537 URL: http://issues.apache.org/jira/browse/LUCENE-537 Project: Lucene - Java Type: Improvement Reporter: Karl Wettin I use the same ngram index for multiple categories, but only want to spell check

[jira] Updated: (LUCENE-537) Refactor of spell check

[ http://issues.apache.org/jira/browse/LUCENE-537?page=all ] Karl Wettin updated LUCENE-537: --- Attachment: lucene_spellcheck.tar.gz the code > Refactor of spell check > --- > > Key: LUCENE-537 > URL: http://issues.apac

Re: Lazy Field Loading

OK, how about a vote on this. I see several ways of implementing the front end to this: 1. Declarative: On construction of a Document, you declare the Field to be Lazy. 2. Implicit: All fields are Lazy 3. Size of Field. Pass into IndexReader.document() the size of the field above which i

Re: Lazy Field Loading

I'd prefer option 4. Users should expect to provide some form of guidance to the engine about how they are going to access the data if it is expected to be retrieved efficiently. Preferably this choice of field loading policy should NOT be "baked in" at index time because index access patterns ca

Re: Lazy Field Loading

I prefer option #4 myself. Also note that a similar issue with patches exists within JIRA: Erik On Mar 31, 2006, at 7:21 AM, Grant Ingersoll wrote: OK, how about a vote on this. I see several ways of implementing the front e

Re: Lazy Field Loading

mark harwood wrote: Preferably this choice of field loading policy should NOT be "baked in" at index time because index access patterns can vary (ruling out options 1 and 3) I don't think option 3 is baked in at indexing time. I think it would look like: | IndexReader.document(int docN

Re: Lazy Field Loading

On 3/31/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: > I prefer option #4 myself. Also note that a similar issue with > patches exists within JIRA: > > Yes, I'd personally find a way to retrieve just fields x,y, and z more useful than

Re: Lazy Field Loading

> I don't think option 3 is baked in at indexing time. Sorry, I misread it. Yes, that is another option. So if options 3 and 4 are about search-time selection (based on size and fieldname respectively) can they be generalized into a more wide-reaching retrieval API? You can imagine a high-level

Re: Lazy Field Loading

Yonik Seeley wrote: On 3/31/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: I prefer option #4 myself. Also note that a similar issue with patches exists within JIRA: Yes, I'd personally find a way to retrieve just fields x,

RE: Date Boosting

Hey Erik, I've got a few more questions. As you've probably realized, I'm somewhat new to Lucene. We're using it to create a new search engine for our site and I've got a few last questions. By the sounds of your first paragraph, I can calculate the date boost and set the date boost on index

[jira] Updated: (LUCENE-536) JEDirectory delete issue

[ http://issues.apache.org/jira/browse/LUCENE-536?page=all ] Aaron Donovan updated LUCENE-536: - Attachment: File.java JEStoreTest.java I went from not deleting enough blocks to deleting too many which is really a much bigger problem. T

Re: Lazy Field Loading

OK, #4 it is. I will most likely submit a patch this weekend. Andrzej Bialecki wrote: Yonik Seeley wrote: On 3/31/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: I prefer option #4 myself. Also note that a similar issue with patches exists within JIRA:

[jira] Commented: (LUCENE-537) Refactor of spell check

[ http://issues.apache.org/jira/browse/LUCENE-537?page=comments#action_12372746 ] Karl Wettin commented on LUCENE-537: This just came on Lucene-users and might explain what I thought was thread safty. I'll take a look at update my refactored code some t