RE: [newbie]problem about range query

I recently submitted a patch that replaces the implementation for multi-term queries (used for fuzzy and wildcard queries) with an implementation that does the union through a priority queue (these are always disjunctions). You *COULD* mimic this change to replace the mechanism used for range quer

Re: [newbie]problem about range query

There is a FAQ thta covers it, I just updated it since it was somewhat out of date and lacked some of the newest (bestest?) info about dealing with this problem... http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-06fafb5d19e786a50fb3dfb8821a6af9f37aa831 In the future, questions about using

Re: Lazy Field Loading

On 4/4/06, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > As I see it, we have a few goals: > 1. Retrieve only the fields someone wants > 2. Retrieve only all fields, but leave some to be lazily loaded > 3. Provide SQL like functionality (as Mark suggested) [a bit harder and > more involved] /*

Re: Lazy Field Loading

Yonik Seeley wrote: On 4/4/06, Grant Ingersoll <[EMAIL PROTECTED]> wrote: I am not sure you need 509 when you have Lazy loading. It would be nice to avoid creating a Field object at all... we have some crazy documents with more than 1000 fields :-) I think the Field object itself ta

Re: Lazy Field Loading

On 4/4/06, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > I am not sure you need 509 when you have Lazy loading. It would be nice to avoid creating a Field object at all... we have some crazy documents with more than 1000 fields :-) I think the Field object itself takes up more room than the data.

[jira] Commented: (LUCENE-538) Using WildcardQuery with MultiSearcher, and Boolean MUST_NOT clause

[ http://issues.apache.org/jira/browse/LUCENE-538?page=comments#action_12373180 ] paul.elschot commented on LUCENE-538: - With this code in doSearch(): System.err.println("Executing query: "+overallQuery); Query qrw = over

Re: Lazy Field Loading

Your right, more flexibility is needed, but it goes beyond just field loading in my mind. I think this is what Doug was getting at (at least partially) with http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard #12 although that focuses on Indexing, I think it should be considered for searc

Re: Semantics of a closed IndexInput

Grant Ingersoll wrote: So, I will take out this test and mark in the javadocs that accessing a field after the reader has been closed is undefined. Does that seem reasonable? Yes, that sounds good to me. Thanks, Doug - To

Re: Lazy Field Loading

On 3/31/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > > > Yes, I'd personally find a way to retrieve just fields x,y, and z more > useful than lazy loading. Thinking a little more, it would be nice if the field reading API was opened

Re: Semantics of a closed IndexInput

So, I will take out this test and mark in the javadocs that accessing a field after the reader has been closed is undefined. Does that seem reasonable? Doug Cutting wrote: Grant Ingersoll wrote: try { value = field.stringValue(); assertTrue("Should not be able to read value: " +

Re: Benchmarking results

For faster Hotspot warm-up you can use Hotspot VM option: -XX:CompileThreshold=NN This option controls number of method invocations/branches before (re-)compiling. Defaults are: 10,000 -server, 1,500 -client. See documentation here: http://java.sun.com/docs/hotspot/VMOptions.html In one of my pre

Re: Benchmarking results

> The times for KinoSearch and Lucene are 5-run ... > is due to cache reassignment.) Therefore, the same > command was > issued on the command line 6 times, separated by > semicolons. The > first iter was discarded, and the rest were > averaged. ... > The maximum memory consumption was meas

Re: Semantics of a closed IndexInput

Grant Ingersoll wrote: try { value = field.stringValue(); assertTrue("Should not be able to read value: " + value + " since the reader is closed", false); } catch (Exception e) { } [ ... ] This test fails, and I don't think it should. The assert in the try block is ac

RE: FilterIndexReader.getVersion

To whom it may concern, I am an IT Recruiter with The Judge Group, I am looking for an individual with the following skill set. This is a permanent position in Chicago. We are looking for 1 server-side, software developer with the following skill set. Salary is 80K-90K. If you get a top n

Re: FilterIndexReader.getVersion

I just fixed this. -Yonik http://incubator.apache.org/solr Solr, The Open Source Lucene Search Server On 4/4/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : Shouldn't FilterIndexReader in 1.9.1 override IndexReader.getVersion() and > : IndexReader.isCurrent()? Currently it doesn't, so getVer

RE: Benchmarking results

Hi, > From: Marvin Humphrey [mailto:[EMAIL PROTECTED] > The test corpus was Reuters-21578, Distribution 1.0. > Reuters-21578 is available from David D. Lewis' professional > home page, currently: > > http://www.research.att.com/~lewis The correct link is http://www.daviddlewis.com/re

[jira] Closed: (LUCENE-413) [PATCH] BooleanScorer2 ArrayIndexOutOfBoundsException + alternative NearSpans

[ http://issues.apache.org/jira/browse/LUCENE-413?page=all ] Yonik Seeley closed LUCENE-413: --- Fix Version: 2.0 Resolution: Fixed Assign To: Yonik Seeley (was: Lucene Developers) Committed! I also did some changing & refactoring on TestSpan

Re: Semantics of a closed IndexInput

Grant Ingersoll wrote: OK. They should not be used, but we have no way of determining if a IndexInput is actually closed, right? At least Lucene does not track it. I run into this issue with Lazy Loading. I can still access the value of a lazy field after the fieldsStream IndexInput is cl

Re: Semantics of a closed IndexInput

OK. They should not be used, but we have no way of determining if a IndexInput is actually closed, right? At least Lucene does not track it. I run into this issue with Lazy Loading. I can still access the value of a lazy field after the fieldsStream IndexInput is closed _if_ I have not made

[jira] Updated: (LUCENE-538) Using WildcardQuery with MultiSearcher, and Boolean MUST_NOT clause

[ http://issues.apache.org/jira/browse/LUCENE-538?page=all ] Helen Warren updated LUCENE-538: Attachment: TestMultiSearchWildCard.java Suite of Junit tests illustrating the problem described in this issue. > Using WildcardQuery with MultiSearcher, and B

[jira] Created: (LUCENE-538) Using WildcardQuery with MultiSearcher, and Boolean MUST_NOT clause

Using WildcardQuery with MultiSearcher, and Boolean MUST_NOT clause --- Key: LUCENE-538 URL: http://issues.apache.org/jira/browse/LUCENE-538 Project: Lucene - Java Type: Bug Components: Search V

Benchmarking results

RESULTS A: 'body' neither stored nor vectorized === configuration avg secs max memory consumed --- Lucene / JVM 1.4

Re: Benchmarkers

On Apr 3, 2006, at 7:08 AM, karl wettin wrote: And if possible, it would be very interesting to see results using - d64 and -d32. And different platforms. I only have easy access to one machine running Java: my G4 1.67 MHz laptop, running Mac OS X 10.4.5. I agree that it would be very in

Re: Benchmarkers

3 apr 2006 kl. 17.26 skrev karl wettin: Solaris: HP DL145, 1 x Dualcore Opteron 2.2 GHz, 4 GB of RAM Linux: HP DL140 with 2x 3.06GHz Xeon CPUs and 4GB of RAM If you want me to, and package the benchmark tests in a way simple for me to run them, I'll run them on these machines for you. The

Re: Benchmarkers

On Apr 3, 2006, at 6:26 PM, Marvin Humphrey wrote: On Apr 3, 2006, at 5:43 PM, Doug Cutting wrote: Marvin Humphrey wrote: Plucene is a Lucene 1.3 port, so it doesn't have max_buffered_docs -- but I can set merge_factor to 1000. I would not recommend that. With a merge factor that high

RE: Date Boosting

: Maybe I'm going about this the wrong way. If you think I am, let me : know. I now realize that this question should be in the lucene users : list but I started it here because I was going to write a new module for : doing this because I couldn't get lucene to do it for me. I'm going to : look

Re: FilterIndexReader.getVersion

: Shouldn't FilterIndexReader in 1.9.1 override IndexReader.getVersion() and : IndexReader.isCurrent()? Currently it doesn't, so getVersion() gives a : NullPointerException, segmentInfos is null. I think you are right, it looks like FilterIndexReader just wasn't updated when those methods were ad