As mentioned before, that syntax seems strange to me. I have never seen an
array used with a match query. I wonder what the resulting Lucene query is.
I think that analyzed/non-analyzed just might be a red herring. What does
the explanation output say?

-- 
Ivan

On Wed, Nov 19, 2014 at 10:24 AM, Ramdev Wudali <agasty...@gmail.com> wrote:

> The fields (I am searching against) are analyzed, by the default analyzer.
> The query as you I noted in my question was generated by using the JAVA
> API, So the array syntax is generated by the API's interpretation.  That
> said, I ran a few more experiments. If the field were not analyzed (unlike
> my non experiment  case),  The query function works and returns the right
> documents. (meaning where both the values exist) in the returned
> documents.  But if they are analyzed, the  operator is not honored.
>
> So now my question is,  why would not analyzed fields cause the operator
> to be honored ?
> and Does the operator field within a nested query depend on if the field
> in the nested field is actually analyzed or not. ?
>
> Ramdev
>
>
>
> On Tuesday, 18 November 2014 14:45:53 UTC-6, Ivan Brusic wrote:
>>
>> I have never seen the array syntax with the match query, so I am not sure
>> what the behavior should be. Since your search terms are not analyzed in
>> your example, a terms query with a minimum match of 100% should work. If
>> not, perhaps creating a single search term of your existing terms?
>>
>> --
>> Ivan
>>
>> On Tue, Nov 18, 2014 at 10:23 AM, Ramdev Wudali <agas...@gmail.com>
>> wrote:
>>
>>> Hi :
>>>    I have the following query :
>>> {
>>>   "query": {
>>>     "bool": {
>>>       "must": {
>>>         "nested": {
>>>           "query": {
>>>             "bool": {
>>>               "must": [
>>>                 {
>>>                   "match": {
>>>                     "NESTED_FIELD.v": {
>>>                       "query": [ "AAPL.OQ", "GOOGL.OQ"],
>>>                       "operator": "and"
>>>
>>>                     }
>>>                   }
>>>                 },
>>>                 {
>>>                   "range": {
>>>                     "NESTED_FIELD.s": {
>>>                       "from": 0.6,
>>>                       "to": null,
>>>                       "include_lower": true,
>>>                       "include_upper": true
>>>                     }
>>>                   }
>>>                 }
>>>               ]
>>>             }
>>>           },
>>>           "path": "NESTED_FIELD"
>>>         }
>>>       }
>>>     }
>>>   },
>>>   "filter": {
>>>     "bool": {
>>>       "must": [
>>>         {
>>>           "range": {
>>>             "DOC_DATE.v": {
>>>               "from": "2014-08-19T20:00:00.000-04:00",
>>>               "to": "2014-10-18T23:59:59.999Z",
>>>               "include_lower": true,
>>>               "include_upper": true
>>>             }
>>>           }
>>>         }
>>>       ]
>>>     }
>>>   }
>>> }
>>>
>>> The behavior I expect is the following :
>>>
>>>  In the documents that are returned, they should contain both values for
>>> the NESTED_FIELD.v (AAPL.OQ and GOOG.OQ) that satisfy the condition where
>>> their corresponding NESTED_FIELD.v range also is satisfied.
>>>
>>> The behavior I see :
>>>    the documents returned contain either one of the values (as in its
>>> got AAPL.OQ (OR) GOOG.OQ (OR) Both.
>>>
>>> I want documents that only have both the values. So the "operator"
>>> :"and" (and its variant "operator":"AND") does not seem to have any effect.
>>> any pointers suggestions regarding this is much appreciated. I am using
>>> the JAVA API to construct my queries. (but I do not think it should matter)
>>>
>>> Thanks
>>>
>>> Ramdev
>>>
>>>
>>>  --
>>> 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.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/elasticsearch/c07cc19b-9ff1-4074-b79c-1861afb7e866%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/elasticsearch/c07cc19b-9ff1-4074-b79c-1861afb7e866%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/20a3c1d1-e2cc-44a5-affe-5b30777bcc8d%40googlegroups.com
> <https://groups.google.com/d/msgid/elasticsearch/20a3c1d1-e2cc-44a5-affe-5b30777bcc8d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQANjUjEjCr%3D0jwf-UB5mEVmFUF8YsJUgVbpLQcEhFpgkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to