[
https://issues.apache.org/jira/browse/LUCENE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17368474#comment-17368474
]
Michael Gibney edited comment on LUCENE-9204 at 6/23/21, 9:30 PM:
------------------------------------------------------------------
I think I see what's going on with disabling graph queries for certain analysis
chains in Elasticsearch:
# ShingleFilter (via
[ShingleTokenFilterFactory|https://github.com/elastic/elasticsearch/blob/d9259ccb3f2881d7e77178f091f1f662a47e9cc0/server/src/main/java/org/elasticsearch/index/analysis/ShingleTokenFilterFactory.java#L116-L124]
and
[CommonAnalysisPlugin|https://github.com/elastic/elasticsearch/blob/d9259ccb3f2881d7e77178f091f1f662a47e9cc0/modules/analysis-common/src/main/java/org/elasticsearch/analysis/common/CommonAnalysisPlugin.java#L475-L485])
#
[CJKBigramFilterFactory|https://github.com/elastic/elasticsearch/blob/d9259ccb3f2881d7e77178f091f1f662a47e9cc0/modules/analysis-common/src/main/java/org/elasticsearch/analysis/common/CJKBigramFilterFactory.java#L70-L78]
This makes sense; and if Solr's not already doing this, then it should. In any
case these are _definitely_ not, as I had wondered, "the very cases where graph
queries would be most useful" :)
However, this still leaves SynonymGraphTokenFilterFactory and
WordDelimiterGraphTokenFilterFactory (in Elasticsearch) as potentially
triggering this kind of expansion (in a manner identical to what's reported in
the above-referenced thread from the solr users list).
was (Author: mgibney):
I think I see what's going on with disabling graph queries for certain analysis
chains in Elasticsearch:
# ShingleFilter (via
[ShingleTokenFilterFactory|https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/index/analysis/ShingleTokenFilterFactory.java#L116-L124]
and
[CommonAnalysisPlugin|https://github.com/elastic/elasticsearch/blob/master/modules/analysis-common/src/main/java/org/elasticsearch/analysis/common/CommonAnalysisPlugin.java#L475-L485])
#
[CJKBigramFilterFactory|https://github.com/elastic/elasticsearch/blob/master/modules/analysis-common/src/main/java/org/elasticsearch/analysis/common/CJKBigramFilterFactory.java#L70-L78]
This makes sense; and if Solr's not already doing this, then it should. In any
case these are _definitely_ not, as I had wondered, "the very cases where graph
queries would be most useful" :)
However, this still leaves SynonymGraphTokenFilterFactory and
WordDelimiterGraphTokenFilterFactory (in Elasticsearch) as potentially
triggering this kind of expansion (in a manner identical to what's reported in
the above-referenced thread from the solr users list).
> Move span queries to the queries module
> ---------------------------------------
>
> Key: LUCENE-9204
> URL: https://issues.apache.org/jira/browse/LUCENE-9204
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have a slightly odd situation currently, with two parallel query
> structures for building complex positional queries: the long-standing span
> queries, in core; and interval queries, in the queries module. Given that
> interval queries solve at least some of the problems we've had with Spans, I
> think we should be pushing users more towards these implementations. It's
> counter-intuitive to do that when Spans are in core though. I've opened this
> issue to discuss moving the spans package as a whole to the queries module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
