lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
Date Fri, 21 Aug 2015 09:28:46 GMT

    [ https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706443#comment-14706443
] 

Jan Høydahl edited comment on SOLR-7888 at 8/21/15 9:28 AM:
------------------------------------------------------------

Lucene guys ([~mikemccand] et.al) are you happy with moving the constant from {{AnalyzingInfixSuggester}}
to {{Lookup}} and make it public, i.e:?
{code}
Index: lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.java
-  protected final static String CONTEXTS_FIELD_NAME = "contexts";
Index: lucene/suggest/src/java/org/apache/lucene/search/suggest/Lookup.java
+  public static final String CONTEXTS_FIELD_NAME = "contexts";
{code}
If you don't want to make the constant part of the public Lucene API, an alternative is to
duplicate the constant into {{org.apache.solr.spelling.suggest.LookupFactory}} for Solr's
use case.

bq. The param name is this latest patch is still suggest.contextFilterQuery as we have not
agreed yet on the right name to adopt
Perhaps {{suggest.cfq}}? 

bq. CONTEXT_ANALYZER_FIELD_TYPE
I'm ok to delay such a param until there is a use case for it.

Another question is choice of query parser for the context filter query: {{StandardQueryParser}}.
Does it make sense to parse the context query using Solr's {{LuceneQParser}}, to fully support
e.g. [localParams|https://cwiki.apache.org/confluence/display/solr/Local+Parameters+in+Queries],
or is this just confusing here since we're not querying a Solr index? A use case would be
ACLs, where the filter query could be hundreds of ACL terms, where you would be better off
doing something like this:
{code}
&suggest.cfq={!terms f=contexts}abc,def,ghi
{code}


was (Author: janhoy):
Lucene guys ([~mikemccand] et.al) are you happy with moving the constant from {{AnalyzingInfixSuggester}}
to {{Lookup}} and make it public, i.e:?
{code}
Index: lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.java
-  protected final static String CONTEXTS_FIELD_NAME = "contexts";
Index: lucene/suggest/src/java/org/apache/lucene/search/suggest/Lookup.java
+  public static final String CONTEXTS_FIELD_NAME = "contexts";
{code}
If you don't want to make the constant part of the public Lucene API, an alternative is to
duplicate the constant into {{org.apache.solr.spelling.suggest.LookupFactory}} for Solr's
use case.

bq. The param name is this latest patch is still suggest.contextFilterQuery as we have not
agreed yet on the right name to adopt
Perhaps {{suggest.cfq}}? 

bq. CONTEXT_ANALYZER_FIELD_TYPE
I'm ok to delay such a param until there is a use case for it.

Another question is choice of query parser for the context filter query: {{StandardQueryParser}}.
Does it make sense to parse the context query using Solr's "lucene" parser, to fully support
e.g. [localParams|https://cwiki.apache.org/confluence/display/solr/Local+Parameters+in+Queries],
or is this just confusing here? I'm thinking that one use of context filtering could be ACLs,
and the filter query could be hundreds of ACL terms, where you would be better off doing something
like this:
{code}
&suggest.cfq={!terms f=contexts}abc def ghi
{code}

> Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter
parameter available in Solr
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-7888
>                 URL: https://issues.apache.org/jira/browse/SOLR-7888
>             Project: Solr
>          Issue Type: New Feature
>          Components: Suggester
>    Affects Versions: 5.2.1
>            Reporter: Arcadius Ahouansou
>            Assignee: Jan Høydahl
>             Fix For: 5.4
>
>         Attachments: SOLR-7888.patch, SOLR-7888.patch, SOLR-7888.patch
>
>
>  LUCENE-6464 has introduced a very flexible lookup method that takes as parameter a BooleanQuery
that is used for filtering results.
> This ticket is to expose that method to Solr.
> This would allow user to do:
> {code}
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:tennis
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:golf
AND contexts:football
> {code}
> etc
> Given that the context filtering in currently only implemented by the {code}AnalyzingInfixSuggester{code}
and by the {code}BlendedInfixSuggester{code}, this initial implementation will support only
these 2 lookup implementations.



--
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


Mime
View raw message