[
https://issues.apache.org/jira/browse/LUCENE-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119085#comment-13119085
]
Martijn van Groningen commented on LUCENE-3482:
-----------------------------------------------
{quote}
What caught my attention in this issue though is that the refactoring seems
extensive enough that we should do performance testing of all the current cases
to ensure there are no regressions. Performance is the most important factor
here, and I'm not sure if trying to introduce more layers of abstraction (when
it's really just an implementation detail) is worth it.
{quote}
I agree with you that any negative performance impact should be kept to an
absolute minimum. That is why I put the refactored collectors in a research
package and kept the unchanged versions around. This allows easy performance
comparison.
bq. The addition of remove() to SentinelIntSet also seems erroneous
That shouldn't have made it in the patch. I'm not using this method in any code.
> Refactor grouping module to be more maintainable
> ------------------------------------------------
>
> Key: LUCENE-3482
> URL: https://issues.apache.org/jira/browse/LUCENE-3482
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/grouping
> Affects Versions: 4.0
> Reporter: Martijn van Groningen
> Fix For: 4.0
>
> Attachments: LUCENE-3482.patch
>
>
> Currently we have 4 types of grouping collectors and 8 concrete subclasses in
> Lucene / Solr. In current architecture for each type of collector two
> concrete subclasses need to be created. An implementation optimized for
> single term based groups and a more general implementation that works with
> MutableValue to also support grouping by functions. If we want for example
> group by IndexDocValues each type of grouping collector needs to have three
> concrete subclasses. This design isn't very maintainable.
> I think it is best to introduce a concept that knows how deals with dealing
> groups for all the different sources. Therefore the grouping module should
> depend on the queries module, so that grouping can reuse the ValueSource
> concept. A term based concrete impl. of this concept knows for example to use
> the DocValues.ord() method. Or more generic concrete impl. will use
> DocValues.ValueFiller.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
