Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
From: Aman Deep singh <amandeep.cool99@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: Solr mm is field Level in case sow is false
Date: Wed, 29 Nov 2017 10:10:18 +0530
References: <88A8E154-43C7-4478-B2FB-FF46DBD4358A@gmail.com>
 <A0E9123F-E27C-41AF-83CA-6CB6BC91485D@gmail.com>
 <CANEGTX_drv9Ai+bZrvtZTFQXMRvoPpBomBwFf-RSv=iH2OVHow@mail.gmail.com>
 <05822906-875C-4A8A-B3B3-FB7D60A74B0D@gmail.com>
To: solr-user@lucene.apache.org
In-Reply-To: <05822906-875C-4A8A-B3B3-FB7D60A74B0D@gmail.com>
Message-Id: <C5D78E1F-DFA2-4824-99C5-F04F58BBC9F9@gmail.com>
archived-at: Wed, 29 Nov 2017 04:40:29 -0000

HI Steve,
I can=E2=80=99t use the copy field because i have multiple types of =
field ,which uses different type of data ,examples are
1. Normal Tokenized field (normal fields)
2. Word deliminated field=20
3. synonyms field (synonyms can be applied on one or two fields not all =
according to our requirement)
4. Ngrams field (model related field, partial word matches)

> On 29-Nov-2017, at 8:30 AM, Steve Rowe <sarowe@gmail.com> wrote:
>=20
> Hi Aman, see my responses inline below.
>=20
>> On Nov 28, 2017, at 9:11 PM, Aman Deep Singh =
<amandeep.cool99@gmail.com> wrote:
>>=20
>> Thanks steve,
>> I got it but my problem is u can't make the every field with same =
analysis,
>=20
> I don=E2=80=99t understand: why can=E2=80=99t you use copy fields with =
all the same analysis?
>=20
>> Is there any chance that sow and mm will work properly ,I don't see =
this in
>> future pipe line also,as their is no jira related to this.
>=20
> I wrote up a description of an idea I had about addressing it in a =
reply to Doug Turnbull's thread on this subject, linked from my blog: =
from =
<http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3c=
F9297676-DE1A-4C2D-928D-76FDBE75FF08@gmail.com%3e>:
>=20
>> In implementing the SOLR-9185 changtes, I considered a compromise =
approach to the term-centric
>> / field-centric axis you describe in the case of differing field =
analysis pipelines: finding
>> common source-text-offset bounded slices in all per-field queries, =
and then producing dismax
>> queries over these slices; this is a generalization of what happens =
in the sow=3Dtrue case,
>> where slice points are pre-determined by whitespace.  However, it =
looked really complicated
>> to maintain source text offsets with queries (if you=E2=80=99re =
interested, you can see an example
>> of the kind of thing I=E2=80=99m talking about in my initial patch on =
<https://issues.apache.org/jira/browse/LUCENE-7533>, which I ultimately =
decided against committing), so I decided to go with per-field dismax =
when
>> structural differences are encountered in the per-field queries.  =
While I won=E2=80=99t be doing
>> any work on this short term, I still think the above-described =
approach could improve the
>> situation in the sow=3Dfalse/differing-field-analysis case.  Patches =
welcome!
>=20
> --
> Steve
> www.lucidworks.com
>=20

Thanks,
Aman Deep Singh=