You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Chris Male (JIRA)" <ji...@apache.org> on 2011/05/19 05:35:48 UTC
[jira] [Issue Comment Edited] (LUCENE-2883) Consolidate Solr &
Lucene FunctionQuery into modules
[ https://issues.apache.org/jira/browse/LUCENE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035967#comment-13035967 ]
Chris Male edited comment on LUCENE-2883 at 5/19/11 3:34 AM:
-------------------------------------------------------------
bq. I think we should move Mutable* over? Grouping module will need all of these, I think? (Ie if we want to allow users to group by arbitrary typed field).
Yup okay.
bq. Hmm good question. This looks to be related to sorting by FQ (SOLR-1297) because some FQs need to be weighted. Not sure what to do here yet... which FQs in particular require this?
Both all of them and not many of them (complicated). The sorting of FQ
functionality is necessary for all FQs in Solr since the user can sort
by any FQ. However the extension made by the SolrSortField is the ability
to create a 'weighted' SortField by passing in a IndexSearcher and having
it stored in a Map. The Map is then made available to any DocValues when
they create their values.
This is when the 'not many' comes into effect. Only a few DocValues implementations
use the contents of the Map. DocFreqValueSource for example uses the IndexSearcher
in the Map. But I suppose there could be many user implementations that do.
SolrSortField is currently used in SolrIndexSearcher to 'weight' the Sorts. I wonder
whether we can simplify this? When ValueSource#getSort is called (which is only in 1
place really), we can pass in the IndexSearcher, meaning the SortField can be 'weighted'
then and there.
Since SolrSortField is only used in this 1 place currently, we can then revisit dropping it?
Do you think its worth opening an issue to address this first?
bq. I think apply 90/10 rule here? Start with the easy-to-move queries? We don't need initial go to be perfect... progress not perfection.
Could we sort the initial commit out and then I can move them over in batches?
Already have a 108k patch, I'd say moving what we can will push it towards 300k
bq. Do you have a sense of whether Solr's FQs are a superset of Lucene's? Ie, is there anything Lucene's FQs can do that Solr's can't?
Solr FQs are hugely more advanced than the ValueSourceQuery based stuff in Lucene.
Its not a full 1 to 1 change since the APIs are slightly different, but I'd say
that we'd want users to use the FQ line of classes. I cant see anything in Lucene's
VSQs that you couldn't do using FQs.
was (Author: cmale):
bq. I think we should move Mutable* over? Grouping module will need all
of these, I think? (Ie if we want to allow users to group by
arbitrary typed field).
Yup okay.
bq. Hmm good question. This looks to be related to sorting by FQ
(SOLR-1297) because some FQs need to be weighted. Not sure what to do
here yet... which FQs in particular require this?
Both all of them and not many of them (complicated). The sorting of FQ
functionality is necessary for all FQs in Solr since the user can sort
by any FQ. However the extension made by the SolrSortField is the ability
to create a 'weighted' SortField by passing in a IndexSearcher and having
it stored in a Map. The Map is then made available to any DocValues when
they create their values.
This is when the 'not many' comes into effect. Only a few DocValues implementations
use the contents of the Map. DocFreqValueSource for example uses the IndexSearcher
in the Map. But I suppose there could be many user implementations that do.
SolrSortField is currently used in SolrIndexSearcher to 'weight' the Sorts. I wonder
whether we can simplify this? When ValueSource#getSort is called (which is only in 1
place really), we can pass in the IndexSearcher, meaning the SortField can be 'weighted'
then and there.
Since SolrSortField is only used in this 1 place currently, we can then revisit dropping it?
Do you think its worth opening an issue to address this first?
bq. I think apply 90/10 rule here? Start with the easy-to-move queries?
We don't need initial go to be perfect... progress not perfection.
Could we sort the initial commit out and then I can move them over in batches?
Already have a 108k patch, I'd say moving what we can will push it towards 300k
bq. Do you have a sense of whether Solr's FQs are a superset of Lucene's?
Ie, is there anything Lucene's FQs can do that Solr's can't?
Solr FQs are hugely more advanced than the ValueSourceQuery based stuff in Lucene.
Its not a full 1 to 1 change since the APIs are slightly different, but I'd say
that we'd want users to use the FQ line of classes. I cant see anything in Lucene's
VSQs that you couldn't do using FQs.
> Consolidate Solr & Lucene FunctionQuery into modules
> -----------------------------------------------------
>
> Key: LUCENE-2883
> URL: https://issues.apache.org/jira/browse/LUCENE-2883
> Project: Lucene - Java
> Issue Type: Task
> Components: core/search
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Fix For: 4.0
>
> Attachments: LUCENE-2883.patch
>
>
> Spin-off from the [dev list | http://www.mail-archive.com/dev@lucene.apache.org/msg13261.html]
--
This message is automatically generated by JIRA.
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