".
> "A-1 Freeman" gets split up into multiple terms, and the "Freeman"
> query matches one of those terms. Text fields are what you use when
> you want matches to have some wiggle room based on your analyzers.
>
> String fields are much more geared towards ex
quot;Freeman"
query matches one of those terms. Text fields are what you use when
you want matches to have some wiggle room based on your analyzers.
String fields are much more geared towards exact matches. No analysis
is done, so a query for "Freeman" would only match docs who
I am trying to do a join, which I have working properly on 2 cores.
One core has report_as, and the other core has debt_id.
If I enter 'report_as: "Freeman", I expect to get 272 results. But I get
557.
When I do a database search on the matched fields, it shows me that
report_as: "Freeman" is ma
> ...so w/o a score param you're getting the default sort: score "desc"
> (descending)...
>
>
> https://lucene.apache.org/solr/guide/8_3/common-query-parameters.html#CommonQueryParameters-ThesortParameter
>
> "If the sort parameter is omitted, sorting is performed as though
> the
>
lucene.apache.org/solr/guide/8_3/common-query-parameters.html#CommonQueryParameters-ThesortParameter
"If the sort parameter is omitted, sorting is performed as though the
parameter were set to score desc."
: If I add ihe sorting needed for cursor, my results change
uot;clt_ref_no":"OWL-2924-8/73847",
"score":23.509575},
{
"clt_ref_no":"U615-2924-8",
"score":19.244316},
{
"clt_ref_no":"M1057-2924-8/88543",
"score":17.650301},
If
then it's a feature of
spellchecking
-Ursprüngliche Nachricht-
Von: Mikhail Khludnev
Gesendet: Montag, 3. September 2018 13:17
An: solr-user
Betreff: Re: Solr suggestions: why are exact matches omitted
I'm afraid only thorough debugging might answer.
On Mon, Sep 3, 2018 at 1
Donnerstag, 30. August 2018 18:01
> An: 'solr-user@lucene.apache.org'
> Betreff: Solr suggestions: why are exact matches omitted
>
> Given the following configuration:
> ...
>
>
> suggest_word_fuzzy
> name="cl
Sorry for not giving up on this issue:
is this "behavior" a feature or a bug?
-Ursprüngliche Nachricht-
Von: Clemens Wyss DEV
Gesendet: Donnerstag, 30. August 2018 18:01
An: 'solr-user@lucene.apache.org'
Betreff: Solr suggestions: why are exact matches omitted
Or do the spellcheck results give an indication that "11000.35" has an exact
match?
-Ursprüngliche Nachricht-
Von: Clemens Wyss DEV
Gesendet: Donnerstag, 30. August 2018 18:01
An: 'solr-user@lucene.apache.org'
Betreff: Solr suggestions: why are exact matche
Given the following configuration:
...
suggest_word_fuzzy
org.apache.solr.spelling.suggest.Suggester
org.apache.solr.spelling.suggest.fst.FuzzyLookupFactory
true
_my_suggest_word
2
You can add an optional (phrase) clause to boost exact matches. If you are
> using (e)dismay
>
> bq=typeahead:"New York World"^50 would do the trick.
>
> Ahmet
>
>
>
> On Tuesday, October 7, 2014 6:55 PM, Shobhit
> wrote:
> Hi,
> I am trying to get
filter and put a
very high boost on _that_ instead...
Best,
Erick
On Tue, Oct 7, 2014 at 12:22 PM, Ahmet Arslan wrote:
> Hi,
>
> You can add an optional (phrase) clause to boost exact matches. If you are
> using (e)dismay
>
> bq=typeahead:"New York World"^50 would
Hi,
You can add an optional (phrase) clause to boost exact matches. If you are
using (e)dismay
bq=typeahead:"New York World"^50 would do the trick.
Ahmet
On Tuesday, October 7, 2014 6:55 PM, Shobhit
wrote:
Hi,
I am trying to get the exact search term coming at top in Solr sear
estHandler name="typeahead" class="solr.SearchHandler">
json
10
true
autosuggest
AND
name_s,pk_id,city_s,state_s,country_s
kindly provide your suggestions to achieve this.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Exact-matches-are-not-comi
I have the following configuration.
fsuggest
name="classname">org.apache.solr.spelling.suggest.Suggester
name="lookupImpl">org.apache.solr.spelling.suggest.fst.FuzzyLookupFactory
text_suggest
text_suggest
suggestio
And once you get past the basics you may want to keep your eye on
http://quepid.io/
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all
at once. Lately, it d
>
> words="stopwords.txt" enablePositionIncrements="true" />
>
>
> mapping="mapping-ISOLatin1Accent.txt"/>
>
>
> pattern="([\.,;:-_])" replacement=" " replace="all"/&
.472066.n3.nabble.com/Exact-matches-tp4116340.html
Sent from the Solr - User mailing list archive at Nabble.com.
--- From: Aleksander Akerø
> Sent: Thursday, January 30, 2014 9:31 AM
>
> To: solr-user@lucene.apache.org
> Subject: Re: KeywordTokenizerFactory - trouble with "exact" matches
>
> Yes, I actually noted that about the filter vs. tokenizer. It's easy to get
> confused if you don
ot; remains for
now.
-- Jack Krupansky
-Original Message-
From: Aleksander Akerø
Sent: Thursday, January 30, 2014 9:31 AM
To: solr-user@lucene.apache.org
Subject: Re: KeywordTokenizerFactory - trouble with "exact" matches
Yes, I actually noted that about the filter vs. tokeni
d" positionIncrementGap="100"> <
> > tokenizer class="solr.KeywordTokenizerFactory"/> > "solr.LowerCaseFilterFactory"/> class="solr.EdgeNGramFilterFactory"
> > minGramSize="2" maxGramSize="25" side="front"/>
;100"> <
> tokenizer class="solr.KeywordTokenizerFactory"/> "solr.LowerCaseFilterFactory"/> minGramSize="2" maxGramSize="25" side="front"/> "solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="25" side="back&q
I also added a bit of extra weighting for the "keyword" field so that exact
matches recieved a higher score.
What this solution doesn't do is to exclude values like "EE 009", when
searching for "FE 009", but they return far down on the list, which for the
customer i
ache.org
Subject: Re: KeywordTokenizerFactory - trouble with "exact" matches
Hi,
I have similar kind of problem where I want search for a words with spaces
in that. And I wanted to search by stripping all the spaces .
I have
Aleksander Akerø
It would be great if you can share the solution how you are handling it on
field basis
--
View this message in context:
http://lucene.472066.n3.nabble.com/KeywordTokenizerFactory-trouble-with-exact-matches-tp4114193p4114435.html
Sent from the Solr - User mailing list archive
ext:
http://lucene.472066.n3.nabble.com/KeywordTokenizerFactory-trouble-with-exact-matches-tp4114193p4114432.html
Sent from the Solr - User mailing list archive at Nabble.com.
number
>> >>
>> >>
>> >>
>> >> *Aleksander Akerø*
>> >> Systemkonsulent
>> >> Mobil: 944 89 054
>> >> E-post: aleksan...@gurusoft.no
>> >>
>> >> *Guruso
t; www.gurusoft.no
> >>
> >>
> >> 2014-01-29 Aruna Kumar Pamulapati
> >>
> >> Hi ,
> >>>
> >>> I think the misunderstanding you are having is about
> >>>
> >>>
> http://wiki.apache.org/solr/AnalyzersTo
LowerCaseTokenizerFactory
>>> lowercase
>>> factory.
>>>
>>> You are correct about KeywordTokenizerFactory but lowercase factory :
>>> Creates
>>> tokens by lowercasing all letters and dropping non-letters.
>>>
>>>
not
match.
-- Jack Krupansky
-Original Message-
From: Aleksander Akerø
Sent: Wednesday, January 29, 2014 9:55 AM
To: solr-user@lucene.apache.org
Subject: Re: KeywordTokenizerFactory - trouble with "exact" matches
update:
Guessing that this has nothing to do with the tokenizer
t KeywordTokenizerFactory but lowercase factory :
>> Creates
>> tokens by lowercasing all letters and dropping non-letters.
>>
>> The best place to play and learn these pipelines is Solr admin panel =>
>> analysis page.
>>
>>
>> thanks,
>> A
gt;
> On Wed, Jan 29, 2014 at 9:05 AM, Aleksander Akerø >wrote:
>
> > Hi, I'll try properly this time.
> >
> > According to solr documentation the solr.KeywordTokenizerFactory should
> not
> > do any tokenizing at all. Thus, if I understand this corr
ould not
> do any tokenizing at all. Thus, if I understand this correctly, it should
> only return exact matches given that this is the only analyzer defined in
> the field type. Such as the following config:
>
> Fieldtypes:
>
Hi, I'll try properly this time.
According to solr documentation the solr.KeywordTokenizerFactory should not
do any tokenizing at all. Thus, if I understand this correctly, it should
only return exact matches given that this is the only analyzer defined in
the field type. Such as the foll
s="true" compressThreshold="10">
>
>
>
>
>
>
> When I analyse the query in solr, I saw that document containing
> pg_series_title_ci:"funny" matches when I do a search for
> pg_series_title_ci:&quo
uot;funny games" and is ranked higher than the document
containing the exact matches. I can use the default string data type but
then the match will be on exact casing.
Thanks,
Sandeep
On 3 April 2013 22:20, Jan Høydahl wrote:
> Can you show us your *_ci field type? Solr does not real
minvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
3. apr. 2013 kl. 15:55 skrev Sandeep Mestry :
> Hi All,
>
> I have a requirement where in exact matches for 2 fields (Series Title,
> Title) should be ranked higher than the partial matches. The configurat
Hi All,
I have a requirement where in exact matches for 2 fields (Series Title,
Title) should be ranked higher than the partial matches. The configuration
looks like below:
edismax
explicit
0.01
*pg_series_title_ci*^500 *title_ci*^300
ky2
> Hello all,
>
>
> i am trying to tune our core for exact matches on a single field (itemNo)
> and having issues getting it to work.
>
> in addition - i need help understanding the output from debugQuery=on where
> it presents the scoring.
>
> my goal is to ge
Hello all,
i am trying to tune our core for exact matches on a single field (itemNo)
and having issues getting it to work.
in addition - i need help understanding the output from debugQuery=on where
it presents the scoring.
my goal is to get exact matches to arrive at the top of the results
Hi Erik,
you are spot on with your guess. I had reinserted my data but apparently
that does not reindex. Delete everything and re-enter was required.
Behaviour now seems to be as desired.
Thank you very much.
PS, thanks for pointing out that the !term is literal. Where can I find
that kind
Roland -
Is it possible that you indexed with a different field type and then changed to
"string" without reindexing? A query on a string will only match literally
the exact value (barring any wildcard/regex syntax), so something is fishy with
your example. Your query example was odd, not su
Hi Erik,
thanks for the response. I have ensured the type is string and that the
field is indexed. No luck though:
(Schema setting under solr/conf):
Query:
Word:apple
Desired result:
apple
Achieved Results:
apple, the red apple, pine-apple, etc, etc
I have also tried your other sugges
It's certainly quite possible with Lucene/Solr. But you have to index the
field to accommodate it. If you literally want an exact match query, use the
"string" field type and then issue a term query. q=field:value will work in
simple cases (where the value has no spaces or colons, or other qu
Hi,
I am trying to do a search that will only match exact words on a field.
I have read somewhere that this is not what SOLR is meant for but I am
still hoping that its possible.
This is an example of what I have tried (to exclude spaces) but the
workaround does not seem to work.
Word:appl
But the problem is that when the search results are displayed , the exact
matches are not filtered to the top.
This should be a simple use case, anyone can suggest when goes wrong ?
Thanks,
Jason
ight for str_category and make it higher . I
>> converted it to lowercase because we cannot expect users to type them in
>> the correct case
>>
>> Thanks
>> Balaji
>>
>> On Thu, Sep 29, 2011 at 3:52 AM, Way Cool wrote:
>>
>>> I will give str
pe them in
> the correct case
>
> Thanks
> Balaji
>
> On Thu, Sep 29, 2011 at 3:52 AM, Way Cool wrote:
>
>> I will give str_category more weight than ts_category because we want
>> str_category to win if they have "exact" matches ( you converted to
>> lo
we want
> str_category to win if they have "exact" matches ( you converted to
> lowercase).
>
> On Mon, Sep 26, 2011 at 10:23 PM, Balaji S wrote:
>
> > Hi
> >
> > You mean to say copy the String field to a Text field or the reverse .
> > This is
I will give str_category more weight than ts_category because we want
str_category to win if they have "exact" matches ( you converted to
lowercase).
On Mon, Sep 26, 2011 at 10:23 PM, Balaji S wrote:
> Hi
>
> You mean to say copy the String field to a Text field or the reve
params "qf=body^4.0 title^5.0 ts_category^21.0" and also sort on
> > SCORE desc
> >
> > When I do a search against "Hospitals" . I get "Hospitalization
> > Management , Hospital Equipment & Supplies " on Top rather than the exact
> > mat
gt; Management , Hospital Equipment & Supplies " on Top rather than the exact
> matches of "Hospitals"
>
> So It would be great , If I could be helped over here
>
>
> Thanks
> Balaji
>
>
>
>
>
>
>
> Thanks in Advance
> Balaji
>
y^4.0 title^5.0 ts_category^21.0" and also sort on
SCORE desc
When I do a search against "Hospitals" . I get "Hospitalization
Management , Hospital Equipment & Supplies " on Top rather than the exact
matches of "Hospitals"
So It would be great , If
> So I figured out part of my
> problem. The string field type doesn't have the
> lowercase filter on it. I can't seem to figure out how
> to add the lowercase filter to it though.
>
> This:
> omitNorms="true">
>
>
>
>
>
> Gives me this error.
> SEVERE: org.apache.solr.common.SolrExceptio
So I figured out part of my problem. The string field type doesn't have
the lowercase filter on it. I can't seem to figure out how to add the
lowercase filter to it though.
This:
Gives me this error.
SEVERE: org.apache.solr.common.SolrException: analyzer without class or
tokenizer & fi
Hi all,
I've searched the archives and web, but I haven't found a great
solution to this issue. I would like to boost the results for things
that match exactly. For example, I have an artist field with possible
values of:
Houston
Whitney Houston
Marques Houston
I would like the Houston
t stemmed), and then search on the appropriate
field.
Is there a better way of doing this?
* CASE 1: index time stemming
input word: house ==> indexed as token: hous
exact-match desired (non-stemmed query):
house ==> house ==> no match --- so if you want exact matches, you
Sorry, this method will not work with tokenized fields I guess. Andy's
approach is the standard in this case, however Yonik's method should also
work.
As for specifying filter queries with SolrJ, use
SolrQuery.addFilterQuery(String
filterQuery) to specify filter queries in code.
On Jan 31, 2008 8
On Jan 31, 2008 10:26 AM, Jörg Kiegeland <[EMAIL PROTECTED]> wrote:
> > I guess you can try specifying your search as a filter query e.g.
> > q=blabla&fq=X:"blabla", which will give back only the exact match.
> >
> I tried this syntax in may Firefox URL field, however seems not to help.
> How do I
I guess you can try specifying your search as a filter query e.g.
q=blabla&fq=X:"blabla", which will give back only the exact match.
I tried this syntax in may Firefox URL field, however seems not to help.
How do I specify a filter query with Solrj (i.e. using SolrQuery)?
Disclaimer: I've only been working (evaluating) Solr for three weeks.
I had exactly this issue, and I found that using a field of type string gave
exact matches. So, if you need to do both substring and exact match queries,
you'll need two fields. One non-tokenized field using class St
re is exactly one document
> matching "blabla" on field X exactly.
> One solution would be to filter the search result for exact-matches on
> client side - however can I shift this filtering to Solr somehow?
>
--
Regards,
Shalin Shekhar Mangar.
ince I know there is exactly one document
matching "blabla" on field X exactly.
One solution would be to filter the search result for exact-matches on
client side - however can I shift this filtering to Solr somehow?
On 11/6/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
> This is fairly straightforward and works well with the DisMax
> handler. Indes the text into three different fields with three
> different sets of analyzers. Use something like this in the
> request handler:
> [...]
>
> exact^
: solr-user@lucene.apache.org
Subject: Re: Score of exact matches
This is fairly straightforward and works well with the DisMax handler.
Indes the text into three different fields with three different sets of
analyzers. Use something like this in the request handler:
0.01
. As a result for example an ad with
> "accounts" in its title is matched when someone runs a query for
> "accountant" because both are stemmed to the "account" word and then
> they match.
>
> Is it somehow possible to give a higher score to exact matches and
&g
one runs a query for
"accountant" because both are stemmed to the "account" word and then
they match.
Is it somehow possible to give a higher score to exact matches and
sort them before matches from stemmed terms?
Close to this is a problem with accents - I can remove accent
both are stemmed to the "account" word and then
they match.
Is it somehow possible to give a higher score to exact matches and
sort them before matches from stemmed terms?
Close to this is a problem with accents - I can remove accents from
both documents and from queries and then run t
69 matches
Mail list logo