You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2009/08/24 22:42:59 UTC

[jira] Issue Comment Edited: (LUCENE-1849) Add OutOfOrderCollector and InOrderCollector subclasses of Collector

    [ https://issues.apache.org/jira/browse/LUCENE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747054#action_12747054 ] 

Uwe Schindler edited comment on LUCENE-1849 at 8/24/09 1:41 PM:
----------------------------------------------------------------

There should also be not only the variation that simply stores docBase in a field. I normally never used that, I always store the reader in a field and then directly operate on the subreader (e.g. for retriving values from the field cache). For me global docIds are unimportant (at least in my collectors). Because of this problem, I had created exactly such a abstract helper class handling this.

For the special case FieldCache, the proposed abstract class simply storing all set values into protected fields does not make sense. This FieldCache-using collectors normally override setNextReader(), where they retrieve the needed arrays from the field cache (whenever a new reader occurs, you can switch your value arrays to the next reader instantly). Collector then only operates on the field cache array, the reader is unimportant. And even the docBase is unimportant. I have such an collector, that uses numerical document ids from the relational database out of the field cache.

Lot's of use-cases... Maybe we should put these helper classes into contrib/queries?

      was (Author: thetaphi):
    There should also be not only the variation that simply stores docBase in a field. I normally never used that, I always store the reader in a field and then directly operate on the subreader (e.g. for retriving values from the field cache). For me global docIds are unimportant (at least in my collectors).

Because of this problem, I had created exactly such a abstract helper class handling this.
  
> Add OutOfOrderCollector and InOrderCollector subclasses of Collector
> --------------------------------------------------------------------
>
>                 Key: LUCENE-1849
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1849
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Search
>    Affects Versions: 2.9
>            Reporter: Tim Smith
>            Priority: Minor
>             Fix For: 2.9
>
>
> I find myself always having to implement these methods, and i always return a constant (depending on if the collector can handle out of order hits)
> would be nice for these two convenience abstract classes to exist that implemented acceptsDocsOutOfOrder() as final and returned the appropriate value

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org