lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn van Groningen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3482) Refactor grouping module to be more maintainable
Date Sun, 02 Oct 2011 22:12:33 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message