lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aman Deep singh <amandeep.coo...@gmail.com>
Subject Re: Solr mm is field Level in case sow is false
Date Wed, 29 Nov 2017 04:40:18 GMT
HI Steve,
I can’t 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 
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:
> 
> Hi Aman, see my responses inline below.
> 
>> On Nov 28, 2017, at 9:11 PM, Aman Deep Singh <amandeep.cool99@gmail.com> wrote:
>> 
>> Thanks steve,
>> I got it but my problem is u can't make the every field with same analysis,
> 
> I don’t understand: why can’t you use copy fields with all the same analysis?
> 
>> 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.
> 
> 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/%3cF9297676-DE1A-4C2D-928D-76FDBE75FF08@gmail.com%3e>:
> 
>> 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=true
case,
>> where slice points are pre-determined by whitespace.  However, it looked really complicated
>> to maintain source text offsets with queries (if you’re interested, you can see
an example
>> of the kind of thing I’m 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’t
be doing
>> any work on this short term, I still think the above-described approach could improve
the
>> situation in the sow=false/differing-field-analysis case.  Patches welcome!
> 
> --
> Steve
> www.lucidworks.com
> 

Thanks,
Aman Deep Singh
Mime
View raw message