;//result[@numFound='1']"
> , "//doc[./str[@name='id']='1']"
> );
>
> assertQ(req("q", "{!complexphrase} iso-latin1:\"caezy~1 traen\"")
> , "//result[@numFound='1']"
ame='id']='1']"
> );
>
> assertQ(req("q", "{!complexphrase} iso-latin1:\"caezy~1 traen\"")
> , "//result[@numFound='1']"
> , "//doc[./str[@name='id']='1']"
>
]='1']"
);
assertQ(req("q", "{!complexphrase} iso-latin1:\"craez* traen\"")
, "//result[@numFound='1']"
, "//doc[./str[@name='id']='1']"
);
assertQ(req("q", "
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 Luc
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 mu
ssage-
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 quit
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:
lob/master/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 wildca
-user@lucene.apache.org
Subject: Re: Complexphrase treats wildcards differently than other query parsers
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
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 out of fear that my head would ex
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 - http://semate
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
awar
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 Traini
Hi list,
I'm trying to search for the term funktionsnedsättning*
In my analyzer chain I use a MappingCharFilterFactory to change ä to a.
So I would expect that funktionsnedsättning* would translate to
funktionsnedsattning*.
If I use e.g. the lucene query parser, this is indeed what happens:
...de
14 matches
Mail list logo
