# Cross field extension to MultiMatch

**URL:** <https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676>\
**Category:** Elasticsearch\
**Created:** [April 24, 2013, 12:54am UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676 "2013-04-24T00:54:15Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![taras](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/taras/32/507_2.png) [@taras](https://discuss.elastic.co/u/taras)\
**Post date:** [April 24, 2013, 12:54am UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676/1 "2013-04-24T00:54:15Z")

</div>

I wrote a patch to MultiMatch query that provides more natural _and_processing when considering multiple fields.

Consider document with fields:

- title: Something
- description: featured on their 1969 album \*Abbey Road[http://en.wikipedia.org/wiki/Abbey\_Road](http://en.wikipedia.org/wiki/Abbey_Road)

- 

- author: Beatles

Now if I take user's input and run a query to match my documents, it would  
be natural to consider ether the dreaded \_all field or a multi\_match query  
like:

_multi\_match:{"query":"Something Beatles", "fields":["title",  
"description", "author"], "operator":"and"}_

Which would get transformed into a boolean query such as:

_(+title:something +title:beatles) (+description:something  
+description:beatles) (+author:something +author: beatles)_

There is no match for our document! From human input perspective often the  
most natural way to AND multi-field search is to ensure each term is  
matched somewhere across all fields such as:

_+(title:something description:something author:something) +(title:beatles  
description:beatles author:beatles)_

My patch does exactly that and it also accounts for use of multiple  
analyzers which may remove tokens from some fields (ex: The Beatles). If a  
token is skipped by an analyzer it will be turned into a should requirement  
on remaining fields instead of a must.

I am using facilities of match query for minimum should match as well as  
fuzzy processing so a new match type felt natural.

_multi\_match:{"query":"Something Beatles", "fields":["title",  
"description", "author"], "type":"across"}_

You can see the patch  
here: [https://github.com/tarass/elasticsearch/commit/8f9fe6c51172f00901b42be621670dd6b2e211ee](https://github.com/tarass/elasticsearch/commit/8f9fe6c51172f00901b42be621670dd6b2e211ee)  
I would like a little feedback if others find this useful and if adding it  
to MultiMatch is the right approach vs writing a plugin. I will also be  
adding more unit tests, but this passes with flying colors on our site.

-Taras

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\
**Post date:** [April 24, 2013, 4:34pm UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676/2 "2013-04-24T16:34:56Z")

</div>

No patch necessary, just use a query string query.

{"query":{"query\_string":{"query":"something  
beatles","fields":["title","description","author"],"default\_operator":"AND"}}}

Thanks,  
Matt Weber

On Tue, Apr 23, 2013 at 5:54 PM, Taras Shkvarchuk [tarass@gmail.com](mailto:tarass@gmail.com) wrote:

> I wrote a patch to MultiMatch query that provides more natural and  
> processing when considering multiple fields.
> 
> Consider document with fields:
> 
> title: Something  
> description: featured on their 1969 album Abbey Road  
> author: Beatles
> 
> Now if I take user's input and run a query to match my documents, it would  
> be natural to consider ether the dreaded \_all field or a multi\_match query  
> like:
> 
> multi\_match:{"query":"Something Beatles", "fields":["title", "description",  
> "author"], "operator":"and"}
> 
> Which would get transformed into a boolean query such as:
> 
> (+title:something +title:beatles) (+description:something  
> +description:beatles) (+author:something +author: beatles)
> 
> There is no match for our document! From human input perspective often the  
> most natural way to AND multi-field search is to ensure each term is matched  
> somewhere across all fields such as:
> 
> +(title:something description:something author:something) +(title:beatles  
> description:beatles author:beatles)
> 
> My patch does exactly that and it also accounts for use of multiple  
> analyzers which may remove tokens from some fields (ex: The Beatles). If a  
> token is skipped by an analyzer it will be turned into a should requirement  
> on remaining fields instead of a must.
> 
> I am using facilities of match query for minimum should match as well as  
> fuzzy processing so a new match type felt natural.
> 
> multi\_match:{"query":"Something Beatles", "fields":["title", "description",  
> "author"], "type":"across"}
> 
> You can see the patch here:  
> [Initial commit for the across type multi-match query · tarass/elasticsearch@8f9fe6c · GitHub](https://github.com/tarass/elasticsearch/commit/8f9fe6c51172f00901b42be621670dd6b2e211ee)  
> I would like a little feedback if others find this useful and if adding it  
> to MultiMatch is the right approach vs writing a plugin. I will also be  
> adding more unit tests, but this passes with flying colors on our site.
> 
> -Taras
> 
> --  
> You received this message because you are subscribed to the Google Groups  
> "elasticsearch" group.  
> To unsubscribe from this group and stop receiving emails from it, send an  
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![taras](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/taras/32/507_2.png) [@taras](https://discuss.elastic.co/u/taras)\
**Post date:** [April 24, 2013, 7:05pm UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676/3 "2013-04-24T19:05:09Z")

</div>

That doesn't do quiet the right thing, but close at first glance.

1. query\_string can't be fed user input because it looks for markup inside  
the query and doesn't treat it purely as text
2. Presence of stopwords and otherwise removed tokens with fields analyzed  
in different manner yields no results. "The Beatles" will not match if  
there is a field with stop word filter and one without.

So if you can think of a different approach, I'm all ears.

On Wednesday, April 24, 2013 9:34:56 AM UTC-7, Matt Weber wrote:

> No patch necessary, just use a query string query.
> 
> {"query":{"query\_string":{"query":"something  
> beatles","fields":["title","description","author"],"default\_operator":"AND"}}}
> 
> Thanks,  
> Matt Weber
> 
> On Tue, Apr 23, 2013 at 5:54 PM, Taras Shkvarchuk \<[tar...@gmail.com](mailto:tar...@gmail.com)\<javascript:\>\>  
> wrote:
> 
> > I wrote a patch to MultiMatch query that provides more natural and  
> > processing when considering multiple fields.
> > 
> > Consider document with fields:
> > 
> > title: Something  
> > description: featured on their 1969 album Abbey Road  
> > author: Beatles
> > 
> > Now if I take user's input and run a query to match my documents, it  
> > would  
> > be natural to consider ether the dreaded \_all field or a multi\_match  
> > query  
> > like:
> > 
> > multi\_match:{"query":"Something Beatles", "fields":["title",  
> > "description",  
> > "author"], "operator":"and"}
> > 
> > Which would get transformed into a boolean query such as:
> > 
> > (+title:something +title:beatles) (+description:something  
> > +description:beatles) (+author:something +author: beatles)
> > 
> > There is no match for our document! From human input perspective often  
> > the  
> > most natural way to AND multi-field search is to ensure each term is  
> > matched  
> > somewhere across all fields such as:
> > 
> > +(title:something description:something author:something)  
> > +(title:beatles  
> > description:beatles author:beatles)
> > 
> > My patch does exactly that and it also accounts for use of multiple  
> > analyzers which may remove tokens from some fields (ex: The Beatles). If  
> > a  
> > token is skipped by an analyzer it will be turned into a should  
> > requirement  
> > on remaining fields instead of a must.
> > 
> > I am using facilities of match query for minimum should match as well as  
> > fuzzy processing so a new match type felt natural.
> > 
> > multi\_match:{"query":"Something Beatles", "fields":["title",  
> > "description",  
> > "author"], "type":"across"}
> > 
> > You can see the patch here:
> 
> [Initial commit for the across type multi-match query · tarass/elasticsearch@8f9fe6c · GitHub](https://github.com/tarass/elasticsearch/commit/8f9fe6c51172f00901b42be621670dd6b2e211ee)
> 
> > I would like a little feedback if others find this useful and if adding  
> > it  
> > to MultiMatch is the right approach vs writing a plugin. I will also be  
> > adding more unit tests, but this passes with flying colors on our site.
> > 
> > -Taras
> > 
> > --  
> > You received this message because you are subscribed to the Google  
> > Groups  
> > "elasticsearch" group.  
> > To unsubscribe from this group and stop receiving emails from it, send  
> > an  
> > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \<javascript:\>.  
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Felix](https://avatars.discourse-cdn.com/v4/letter/f/aeb1de/32.png) [@Felix](https://discuss.elastic.co/u/Felix)\
**Post date:** [September 21, 2013, 8:27am UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676/4 "2013-09-21T08:27:29Z")

</div>

I'd love to have this feature!  
Why don't you create an issue at elasticsearch with a pull request?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 2:15am UTC](https://discuss.elastic.co/t/cross-field-extension-to-multimatch/11676/5 "2017-07-06T02:15:14Z")

</div>