[
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: [email protected]
For additional commands, e-mail: [email protected]
