You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Alessandro Benedetti (JIRA)" <ji...@apache.org> on 2016/03/14 12:09:33 UTC
[jira] [Comment Edited] (SOLR-8672) Unique Suggestions getter in
Solrj
[ https://issues.apache.org/jira/browse/SOLR-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192984#comment-15192984 ]
Alessandro Benedetti edited comment on SOLR-8672 at 3/14/16 11:09 AM:
----------------------------------------------------------------------
Hi David,
I agree this was a simple contribution to try to have a quick fix to the problem at least at SolrJ level.
I thought more about the problem, and I agree with Tomas.
I even think we should NOT include my own patch here, this is my reason :
if we add now this SolrJ support and in the future we add the suggester solrconfig.xml parameter, users are going to be confused.
The solrconfig.xml approach will be the most efficient and recommended but the presence of this method SolrJ side could grow confusion in people minds and generate some scenario where you use the Solrj method but actually going to the solr configuration would be optimal.
Does this make sense ?
I will proceed in studying a little bit LUCENE-6336 and some internals, I will end up with a proposal here and in the mailing list ( with related Jira) .
Not sure if a Dedup Wrapper is the best way, ideally I don't want to generate at all duplicates, avoid a wrapper reading the list again and removing duplicates.
I will spend some time on that!
Cheers
was (Author: alessandro.benedetti):
Hi David,
I agree this was a simple contribution to try to have a quick fix to the problem at least at SolrJ level.
I thought more about the problem, and I agree with Tomas.
I even think we should NOT include my own patch here, this is my reason :
if we add now this SolrJ support and in the future we add the suggester solrconfig.xml parameter, users are going to be confused.
The solrconfig.xml approach will be the most efficient and recommended but the presence of this method SolrJ side could grow confusion in people minds and generate some scenario where you use the Solrj method but actually going to the solr configuration would be optimal.
Does this make sense ?
I will proceed in studying a little bit LUCENE-6636 and some internals, I will end up with a proposal here and in the mailing list ( with related Jira) .
Not sure if a Dedup Wrapper is the best way, ideally I don't want to generate at all duplicates, avoid a wrapper reading the list again and removing duplicates.
I will spend some time on that!
Cheers
> Unique Suggestions getter in Solrj
> ----------------------------------
>
> Key: SOLR-8672
> URL: https://issues.apache.org/jira/browse/SOLR-8672
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: 5.4.1
> Reporter: Alessandro Benedetti
> Attachments: SOLR-8672.patch
>
>
> Currently all the suggesters based on full field content retrieval gives back possibly duplicated suggestions.
> First observation , related the suggester domain, is that is unlikely we need to return duplicates ( actually we don't return the id of the document, or anything else, so having duplicates is arguably not a benefit) .
> I propose at least to offer via SolrJ the possibility of getting the suggestions without duplicates.
> Any feedback is welcome.
> The patch provided is really simple.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org