Return-Path: 
 <solr-user-return-102847-apmail-lucene-solr-user-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D891D11FFE
	for <apmail-lucene-solr-user-archive@minotaur.apache.org>;
 Thu, 31 Jul 2014 06:55:46 +0000 (UTC)
Received: (qmail 39934 invoked by uid 500); 31 Jul 2014 06:55:42 -0000
Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org
Received: (qmail 39866 invoked by uid 500); 31 Jul 2014 06:55:42 -0000
Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:solr-user-help@lucene.apache.org>
List-Unsubscribe: <mailto:solr-user-unsubscribe@lucene.apache.org>
List-Post: <mailto:solr-user@lucene.apache.org>
List-Id: <solr-user.lucene.apache.org>
Reply-To: solr-user@lucene.apache.org
Delivered-To: mailing list solr-user@lucene.apache.org
Received: (qmail 39855 invoked by uid 99); 31 Jul 2014 06:55:42 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jul 2014 06:55:42 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of thomas.engelke@posteo.de
 designates 89.146.194.165 as permitted sender)
Received: from [89.146.194.165] (HELO posteo.de) (89.146.194.165)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jul 2014 06:55:37 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.posteo.de (Postfix) with ESMTP id C031F25A2107
	for <solr-user@lucene.apache.org>; Thu, 31 Jul 2014 08:55:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at posteo.de
Received: from posteo.de ([10.125.125.178]) (using TLS)
	by localhost (amavis1.posteo.de [10.125.125.165]) (amavisd-new, port 10026)
	with ESMTPS id RnOh1RcjhAa8 for <solr-user@lucene.apache.org>;
	Thu, 31 Jul 2014 08:55:11 +0200 (CEST)
Received: from mail.posteo.de (localhost [127.0.0.1])
	by mail.posteo.de (Postfix) with ESMTPSA id F3B282C298F
	for <solr-user@lucene.apache.org>; Thu, 31 Jul 2014 08:55:10 +0200 (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_e3e54ad7a36c35c77709ef3366ef6282"
Date: Thu, 31 Jul 2014 08:55:10 +0200
From: Thomas Michael Engelke <thomas.engelke@posteo.de>
To: <solr-user@lucene.apache.org>
Subject: Re: Ranking based on match position in field
Organization: Wehlmann Marketing GmbH
In-Reply-To: <1406724521.39210.YahooMailNeo@web124705.mail.ne1.yahoo.com>
References: <494539f34c8815323c294b238c5d3ff2@posteo.de>
 <1406724521.39210.YahooMailNeo@web124705.mail.ne1.yahoo.com>
Message-ID: <8a271614a3fb9d1397c18a7ed149f35a@posteo.de>
X-Sender: thomas.engelke@posteo.de
User-Agent: Posteo Webmail
X-Virus-Checked: Checked by ClamAV on apache.org

--=_e3e54ad7a36c35c77709ef3366ef6282
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

 Hi,

thanks for the link. I've upgraded from the used 4.7 to the
recent 4.9 version. I've tried to use the new feature with this query in
the admin interface using edismax:

description:K=C3=BChler^~1^5

However,
the result seems to stay the same:

<lst name=3D"debug">
 <str
name=3D"rawquerystring">description:K=C3=BChler~1^5</str>
 <str
name=3D"querystring">description:K=C3=BChler~1^5</str>
 <str
name=3D"parsedquery">(+description:k=C3=BChler~1^5.0)/no_coord</str>
 <str
name=3D"parsedquery_toString">+description:k=C3=BChler~1^5.0</str>
 <lst
name=3D"explain">
 <str name=3D"17411">
2.334934 =3D (MATCH)
weight(description:k=C3=BChler^5.0 in 4080) [DefaultSimilarity], result of:

2.334934 =3D score(doc=3D4080,freq=3D1.0 =3D termFreq=3D1.0
), product of:

0.99999994 =3D queryWeight, product of:
 5.0 =3D boost
 6.226491 =3D
idf(docFreq=3D64, maxDocs=3D12099)
 0.03212082 =3D queryNorm
 2.3349342 =3D
fieldWeight in 4080, product of:
 1.0 =3D tf(freq=3D1.0), with freq of:
 1.0
=3D termFreq=3D1.0
 6.226491 =3D idf(docFreq=3D64, maxDocs=3D12099)
 0.375 =3D
fieldNorm(doc=3D4080)
</str>
 <str name=3D"19085">
2.334934 =3D (MATCH)
weight(description:k=C3=BChler^5.0 in 5754) [DefaultSimilarity], result of:

2.334934 =3D score(doc=3D5754,freq=3D1.0 =3D termFreq=3D1.0
), product of:

0.99999994 =3D queryWeight, product of:
 5.0 =3D boost
 6.226491 =3D
idf(docFreq=3D64, maxDocs=3D12099)
 0.03212082 =3D queryNorm
 2.3349342 =3D
fieldWeight in 5754, product of:
 1.0 =3D tf(freq=3D1.0), with freq of:
 1.0
=3D termFreq=3D1.0
 6.226491 =3D idf(docFreq=3D64, maxDocs=3D12099)
 0.375 =3D
fieldNorm(doc=3D5754)
</str>

Am I using this feature wrong?

Am
30.07.2014 14:48 schrieb Ahmet Arslan:=20

> Hi,
>=20
> Please see :
https://issues.apache.org/jira/browse/SOLR-3925 [1]
>=20
> Ahmet
>=20
> On
Wednesday, July 30, 2014 2:39 PM, Thomas Michael Engelke
<thomas.engelke@posteo.de> wrote:
> Hi,
>=20
> an example. We have 2
records with this data in the same field
> (description):
>=20
> 1:
Lufthutze vor K=C3=BChler Bj 62-65, DS
> 2: K=C3=BChler HY im
> Austausch,
Altteilpfand 250 Euro
>=20
> A search with the parameters
>
'description:K=C3=BChler' does provide this debug:
>=20
> 2.3234584 =3D (MATCH)
>
weight(description:k=C3=BChler in 4053) [DefaultSimilarity], result of:
>=20
>
2.3234584 =3D fieldWeight in 4053, product of:
> 1.0 =3D tf(freq=3D1.0),
with
> freq of:
> 1.0 =3D termFreq=3D1.0
> 6.195889 =3D idf(docFreq=3D69,
maxDocs=3D12637)
>=20
> 0.375 =3D fieldNorm(doc=3D4053)
> </str>
> <str
name=3D"16946">
> 2.3234584 =3D
> (MATCH) weight(description:k=C3=BChler in 5729)
[DefaultSimilarity], result
> of:
> 2.3234584 =3D fieldWeight in 5729,
product of:
> 1.0 =3D tf(freq=3D1.0),
> with freq of:
> 1.0 =3D termFreq=3D1.0
>
6.195889 =3D idf(docFreq=3D69,
> maxDocs=3D12637)
> 0.375 =3D
fieldNorm(doc=3D5729)
>=20
> As you can see, both get
> the exact same
score. However, we would like to rank the second document
> higher, on
the basis that the search term occurs further to the left of
> the
field.
>=20
> Is there a component/setting that can do that?




Links:
------
[1] https://issues.apache.org/jira/browse/SOLR-3925

--=_e3e54ad7a36c35c77709ef3366ef6282--