[
https://issues.apache.org/jira/browse/LUCENE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054110#comment-13054110
]
Chris Male edited comment on LUCENE-3232 at 6/23/11 9:28 PM:
-------------------------------------------------------------
{quote}
I wonder if we should name this module something more specific, eg docvalues?
values?
Should we also move over ValueSource, *DocValues, FieldCacheSource? I think,
then, Solr 3.x grouping could cutover and then group by other field types.
{quote}
To be honest, that wasn't my plan :D
My plan is to first move these to a Common module which will serve basically as
a utility module for other modules. The MutableValue classes are useful in a
number of places (or will be in the future). I envisage other useful utility
like classes going into this module in the future too. Solr for example has a
number of very useful utilities that might be of benefit.
As such, it doesn't really relate to FunctionQuerys or ValueSources.
The next step once this is complete is to do what I originally intended and
make a Queries module and push FunctionQuery and all the ValueSources /
DocValues into that.
In the end you get the following structure:
{code}
modules/
common/
(MutableValue*)
queries/
(FunctionQuery, *DocValues, *ValueSource, Queries from contrib/queries)
{code}
Seem reasonable?
was (Author: cmale):
{quote}
I wonder if we should name this module something more specific, eg docvalues?
values?
Should we also move over ValueSource, *DocValues, FieldCacheSource? I think,
then, Solr 3.x grouping could cutover and then group by other field types.
{quote}
To be honest, that wasn't my plan :D
My plan is to first move these to a Common module which will serve basically as
a utility module for other modules. The MutableValue classes are useful in a
number of places (or will be in the future). I envisage other useful utility
like classes going into this module in the future too. Solr for example has a
number of very useful utilities that might be of benefit.
As such, it doesn't really relate to FunctionQuerys or ValueSources.
The next step once this is complete is to do what I originally intended and
make a Queries module and push FunctionQuery and all the ValueSources /
DocValues into that.
In the end you get the following structure:
modules/
common/
(MutableValue*)
queries/
(FunctionQuery, *DocValues, *ValueSource, Queries from contrib/queries)
Seem reasonable?
> Move MutableValues to Common Module
> -----------------------------------
>
> Key: LUCENE-3232
> URL: https://issues.apache.org/jira/browse/LUCENE-3232
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: core/search
> Reporter: Chris Male
> Fix For: 4.0
>
> Attachments: LUCENE-3232.patch, LUCENE-3232.patch
>
>
> Solr makes use of the MutableValue* series of classes to improve performance
> of grouping by FunctionQuery (I think). As such they are used in ValueSource
> implementations. Consequently we need to move these classes in order to move
> the ValueSources.
> As Yonik pointed out, these classes have use beyond just FunctionQuerys and
> might be used by both Solr and other modules. However I don't think they
> belong in Lucene core, since they aren't really related to search
> functionality. Therefore I think we should put them into a Common module,
> which can serve as a dependency to Solr and any module.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
