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 <sar...@gmail.com> wrote: > > Hi Aman, see my responses inline below. > >> On Nov 28, 2017, at 9:11 PM, Aman Deep Singh <amandeep.coo...@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-76fdbe75f...@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
