Re: time for "ant test"?

Hi all, I'm not familiar with this part of the code (SpanxxQuery.rewrite), but I was following the discussions and a question I had in mind from the begining: Since these methods seem to be similar, or at least some part of the code, isn't it possible to use some refactorings, a base class (a

[jira] Resolved: (LUCENE-84) Enhanced FSDirectory that allow lock disable via API

[ http://issues.apache.org/jira/browse/LUCENE-84?page=all ] Otis Gospodnetic resolved LUCENE-84: Fix Version: 1.9 Resolution: Fixed It looks like this old issue was fixed at some point, as FSDirectory now has the following method: publi

[jira] Closed: (LUCENE-84) Enhanced FSDirectory that allow lock disable via API

[ http://issues.apache.org/jira/browse/LUCENE-84?page=all ] Otis Gospodnetic closed LUCENE-84: -- > Enhanced FSDirectory that allow lock disable via API > > > Key: LUCENE-84 > URL: ht

[jira] Commented: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=comments#action_12330499 ] Hoss Man commented on LUCENE-323: - 2cents: Even if the DistributingMultiFieldQueryParser isn't deemd "core worthy" (the comments suggest it should be treated more as an examp

DO NOT REPLY [Bug 32088] - Index Writer constructor flags unclear - and annoying in certain cases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[jira] Commented: (LUCENE-301) Index Writer constructor flags unclear - and annoying in certain cases

[ http://issues.apache.org/jira/browse/LUCENE-301?page=comments#action_12330502 ] Dan Armbrust commented on LUCENE-301: - Could this be addresses or WONT FIXED before the 1.9 release? > Index Writer constructor flags unclear - and annoying in certain ca

constant score queries / function scores and idf

For something like ConstantScoreRangeQuery, or a query that scores based on field contents, it doesn't make sense to have an idf() (and hence I leave it out). However, I'm worried about how these constant scores will vary with respect to other clauses when the index changes size. Does it make sens

Re: score based on field value

Here is another prototype. Field value retrieval has been decoupled from function calculation, so one will be able to use a field of any type with the same function class. Comments? If not, I think this may be the version I clean up, implement sources for Integer and Ordinal fields, and submit to

[jira] Commented: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=comments#action_12330532 ] Chuck Williams commented on LUCENE-323: --- Thanks Hoss, that's nice to hear. I've been out of the community for a while doing other things, but am about to start a large

[jira] Commented: (LUCENE-383) ConstantScoreRangeQuery - fixes "too many clauses" exception

[ http://issues.apache.org/jira/browse/LUCENE-383?page=comments#action_12330537 ] Yonik Seeley commented on LUCENE-383: - > One problem with the current score is that it is not really bound > to a maximum, so it is difficult to choose a good constant scor

[jira] Created: (LUCENE-439) Filters need hashCode() and equals()

Filters need hashCode() and equals() Key: LUCENE-439 URL: http://issues.apache.org/jira/browse/LUCENE-439 Project: Lucene - Java Type: Bug Components: Search Versions: 1.9 Reporter: Yonik Seeley Filters need to i

[jira] Updated: (LUCENE-439) Filters need hashCode() and equals()

[ http://issues.apache.org/jira/browse/LUCENE-439?page=all ] Yonik Seeley updated LUCENE-439: Attachment: filter_equals_hashCodes.txt patch for non-deprecated filters > Filters need hashCode() and equals() > > >