\"caezy~1 traen\"")
> , "//result[@numFound='1']"
> , "//doc[./str[@name='id']='1']"
> );
>
> assertQ(req("q", "{!complexphrase} iso-latin1:\"craez* traen\"")
> , "//result[@numFound='1']"
, "//doc[./str[@name='id']='1']"
> );
>
> assertQ(req("q", "{!complexphrase} iso-latin1:\"craez* traen\"")
> , "//result[@numFound='1']"
> , "//doc[./str[@name='id']='1']"
> );
>
>
ertQ(req("q", "{!complexphrase} iso-latin1:\"*aezy traen\"")
, "//result[@numFound='1']"
, "//doc[./str[@name='id']='1']"
);
assertQ(req("q", "{!complexphrase} iso-latin1:\"crae*y traen\"")
,
Thanks a lot for your effort, Tim.
Looking at it from the Solr side, I see some use of local classes. The
snippet below in particular caught my eye (in
solr/core/src/java/org/apache/solr/search/ComplexPhraseQParserPlugin.java).
The instance of ComplexPhraseQueryParser is not the clean one from
After some more digging, I'm wrong even at the Lucene level.
When I use the CustomAnalyzer and make my UC vowel mock filter MultitermAware,
I get this with Lucene in trunk:
"the* quick~" name:thE* name:qUIck~2 name:thE name:qUIck
So, there's room for improvement with phrases, but the regular
-
From: Bjarke Buur Mortensen [mailto:morten...@eluence.com]
Sent: Thursday, October 5, 2017 8:52 AM
To: solr-user@lucene.apache.org
Subject: Re: Complexphrase treats wildcards differently than other query parsers
Thanks Tim,
that might be what I'm experiencing. I'm actually quite certain
aster/lucene-5205
> [2] https://mvnrepository.com/artifact/org.tallison.lucene/
> lucene-5205/6.6-0.1
>
> -----Original Message-
> From: Bjarke Buur Mortensen [mailto:morten...@eluence.com]
> Sent: Thursday, October 5, 2017 6:28 AM
> To: solr-user@lucene.apache.org
> Subject: Re: C
/lucene-5205/src/test/java/org/apache/lucene/queryparser/spans/TestAdvancedAnalyzers.java#L117
-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org]
Sent: Thursday, October 5, 2017 8:02 AM
To: solr-user@lucene.apache.org
Subject: RE: Complexphrase treats wildcards differ
@lucene.apache.org
Subject: Re: Complexphrase treats wildcards differently than other query parsers
2017-10-05 11:29 GMT+02:00 Emir Arnautović <emir.arnauto...@sematext.com>:
> Hi Bjarke,
> You are right - I jumped into wrong/old conclusion as the simplest
> answer to your question
2017-10-05 11:29 GMT+02:00 Emir Arnautović :
> Hi Bjarke,
> You are right - I jumped into wrong/old conclusion as the simplest answer
> to your question.
No problem :-)
I guess looking at the code could give you an answer.
>
This is what I would like to avoid
Hi Bjarke,
You are right - I jumped into wrong/old conclusion as the simplest answer to
your question. I guess looking at the code could give you an answer.
Thanks,
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training -
Well, according to
https://lucidworks.com/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/
multiterm means
wildcard
range
prefix
so it is that way i'm using the word. That same article explains how
analysis will be performed with wildcards if the analyzers are multi-term
Hi Bjarke,
It is not multiterm that is causing query parser to skip analysis chain but
wildcard. The majority of query parsers do not analyse query string if there
are wildcards.
HTH
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support
13 matches
Mail list logo