I really liked HItCollector and hate to give up the name ... However
Collector is fine with me either, and it is at least more generic than
HitCollector ...
Hitable sounds too aggressive/violent to me :)
BTW, I guess I should create some new searcher API which receives this
Collector class (is Co
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/778/changes
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Alves updated LUCENE-1567:
---
Attachment: lucene_trunk_FlexQueryParser_2009March26_v3.patch
I cleaned up all the javadocs on this
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Alves updated LUCENE-1567:
---
Attachment: (was: lucene_trunk_FlexQueryParser_2009March26.patch)
> New flexible query parser
>
PooledSegmentReader, pools SegmentReader underlying byte arrays
---
Key: LUCENE-1574
URL: https://issues.apache.org/jira/browse/LUCENE-1574
Project: Lucene - Java
Issue Type: Improv
> I think ResultsCollector (or maybe ResultCollector) is my favorite so far...
>
> But how about simply Collector? (I realize it's very generic... but
> we don't collect anything else in Lucene?).
That's exactly what I'm using in my app -> abstract class Collector
extends HitCollector, that serves
On Thu, Mar 26, 2009 at 06:03:07PM -0400, Michael McCandless wrote:
> But how about simply Collector? (I realize it's very generic... but
> we don't collect anything else in Lucene?).
+1
Honorable mention to "NitPicker", LOL.
Marvin Humphrey
--
On Thu, Mar 26, 2009 at 5:28 PM, Marvin Humphrey wrote:
> On Thu, Mar 26, 2009 at 04:01:26PM +0200, Shai Erera wrote:
>> I still think that ResultsCollector does what you describe. It simply
>> collects results, while the word 'result' is quite *open* and does not
>> commit to anything ...
>
> Ano
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689680#action_12689680
]
Luis Alves commented on LUCENE-1567:
HI Grant and Micheal
I faxed the CLA today.
> Ne
On Thu, Mar 26, 2009 at 04:01:26PM +0200, Shai Erera wrote:
> I still think that ResultsCollector does what you describe. It simply
> collects results, while the word 'result' is quite *open* and does not
> commit to anything ...
Another advantage of "ResultsCollector" is that the name suggests go
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Alves updated LUCENE-1567:
---
Attachment: lucene_trunk_FlexQueryParser_2009March26.patch
Here is an updated version of the patch w
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689629#action_12689629
]
Tim Smith commented on LUCENE-831:
--
One requirement i would like to request is the ability
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689624#action_12689624
]
Uwe Schindler commented on LUCENE-831:
--
I will attach my comments regarding the proble
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689620#action_12689620
]
Michael Busch commented on LUCENE-831:
--
Shall we try to gather all requirements we hav
[
https://issues.apache.org/jira/browse/LUCENE-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1573:
---
Attachment: LUCENE-1573.patch
Attached patch. All tests pass, including a new one t
Is it also worth while to check if a static signature can be added to mails
with instructions
Or a link to the apache mail instructions?
It will reduce a lot of repeat questions.
On Thu, Mar 26, 2009 at 2:46 PM, Chris Hostetter
wrote:
>
> : Every now and again, someone emails me off list asking
: Every now and again, someone emails me off list asking to be removed from the
: list and I always forward them to Erik, b/c I know he is a moderator.
: However, I was wondering who else is besides Erik, since, AIUI, there needs to
: be at least 3 in ASF-land, right?
:
: So, if you're a list mod
In 1483 Doug had also suggested:
* Hitable
I suppose Collector shouldn't really be in the name, since the class
may not actually "collect" the results (eg if it simply counts).
Mike
Marvin Humphrey wrote:
> On Thu, Mar 26, 2009 at 08:44:57AM -0400, Michael McCandless wrote:
>
>> do you have
Shai Erera wrote:
> BTW Mike, I noticed that TopFieldDocCollector extends TopScoreDocCollector.
Weird. Probably we could put that back to extending [deprecated]
TopDocCollector?
> That is a problem if we want to make TSDC final. Now, TFDC is marked
> deprecated, so it will be removed in the fut
Shai Erera wrote:
>> I may have lost the context here... but here's what I thought we were
>> talking about.
>>
>> If we choose the interface option (adding a "ProvidesTopDocsResults"
>> (say) interface), then you would create method
>> renderResults(ProvidesTopDocResults).
>>
>> Then, any collect
I still think that ResultsCollector does what you describe. It simply
collects results, while the word 'result' is quite *open* and does not
commit to anything ...
How about dropping the word Collector, since it might not collect anything,
and just save the highest score, or compute some facets ..
> On Thu, Mar 26, 2009 at 08:44:57AM -0400, Michael McCandless wrote:
>
>> do you have an alternative?
>
> Brainstorming
>
> * Harvester
> * Trawler
> * HitPicker
> * HitGrabber
>
> Marvin Humphrey
NitPicker - that absolutely made my day
--
Kirill Zakharenko/Кирилл Захаренко (ear...@gma
On Thu, Mar 26, 2009 at 08:44:57AM -0400, Michael McCandless wrote:
> do you have an alternative?
Brainstorming
* Harvester
* Trawler
* HitPicker
* HitGrabber
Marvin Humphrey
-
To unsubscribe, e-mail: java-dev-uns
> BTW, I like the name ResultsCollector, as it's just like HitCollector, but
> does not commit too much to "hits" .. i.e., facets aren't hits ... I think?
What this class consumes and what it produces is a totally different
thing. HitCollector always collects 'hits', and then produces whatever
imp
BTW Mike, I noticed that TopFieldDocCollector extends TopScoreDocCollector.
That is a problem if we want to make TSDC final. Now, TFDC is marked
deprecated, so it will be removed in the future.
I think an easy fix is just to have TFDC extend TopResultsCollector, right?
On Thu, Mar 26, 2009 at 2:52
>
> I may have lost the context here... but here's what I thought we were
> talking about.
>
> If we choose the interface option (adding a "ProvidesTopDocsResults"
> (say) interface), then you would create method
> renderResults(ProvidesTopDocResults).
>
> Then, any collector implementing that inte
Earwin Burrfoot wrote:
> I'd say it is a bad name. Raw hit is way far from being result of a search.
First off, from Lucene's standpoint, the docID *is* the result of the
search. Your application will do further things (load titles, do
higlighting, etc.) with that result.
Second off, since Res
IndexWriter does not do the right thing when a Thread is interrupt()'d
--
Key: LUCENE-1573
URL: https://issues.apache.org/jira/browse/LUCENE-1573
Project: Lucene - Java
Issu
I'd say it is a bad name. Raw hit is way far from being result of a search.
If you're already breaking back compat with 3.0 release (by
incrementing java version), maybe its worthy to break it in some more
places, just so ugly names like MRHC and special code paths that check
for n-year-old interf
You're right ... I missed that. My fault :)
On Thu, Mar 26, 2009 at 12:18 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Mark Miller wrote:
> > bq. I personally don't understand why MRHC was invented in the first
> place.
> >
> > The evolution of MRHC is in the comments of LUCENE-1
On Mar 26, 2009, at 6:55 AM, Michael McCandless wrote:
think we need to deprecate HC, in favor of MRHC (or if we can think
of a better name... ResultCollector?).
I like your suggestion for the name.
-
To unsubscribe, e-mai
[
https://issues.apache.org/jira/browse/LUCENE-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1572:
---
Fix Version/s: 2.9
> luceneweb
> --
>
> Key: LUCENE-1572
>
Shai Erera wrote:
>> The difference is for the new code, it's an upcast, which catches any
>> errors at compile time, not run time. The compiler determines that
>> the class implements the required interface.
>
> I still don't understand how a compiler can detect at compilation time that
> a Hit
Mark Miller wrote:
> bq. I personally don't understand why MRHC was invented in the first place.
>
> The evolution of MRHC is in the comments of LUCENE-1483 - a lot of comments
> to wade through though.
MRHC was created because simply adding setNextReader to HC would break
back compat, because co
luceneweb
--
Key: LUCENE-1572
URL: https://issues.apache.org/jira/browse/LUCENE-1572
Project: Lucene - Java
Issue Type: Bug
Components: Examples
Affects Versions: 2.4
Environment: Windows XP
Report
35 matches
Mail list logo
