NEST Fluent DSL querying some URL field - elasticsearch

Question

Got some question related to NEST. Below are some documents in my ES.
As you can see I already insert some entry in my ES. I tried do some query something like this:
var response = elastic.Search<ESIntegrationLog>(s => s
.Index("20160806")
.Type("esintegrationlog")
.Query(q =>
q.Term(p => p.CalledBy, "lazada")
)
.Sort(ss => ss.Descending(p => p.CalledOn))
.Take(300)
);
The outcome is just as I expected, I do found the entry. But when I tried to query by 'callPoint', I somehow cannot find any result. Below is the code:
var response = elastic.Search<ESIntegrationLog>(s => s
.Index("20160806")
.Type("esintegrationlog")
.Query(q =>
q.Term(p => p.CallPoint, "/cloudconnect/api/xxxxxxx/v1")
)
.Sort(ss => ss.Descending(p => p.CalledOn))
.Take(300)
);
I do already tried to encode the URL, but still does not find anything. Any ideas?
Update: I solve the case using 'match'.
.Query(q =>
//q.Term(p => p.CallPoint, "abcdefg")
q.MatchPhrasePrefix(c=> c.Field(d=> d.CallPoint).Query("/cloudconnect/api/xxxxxxx/v1"))
)

Answer 1

I suspect that callPoint is an analyzed string field, which has been analyzed by the standard analyzer. You'll be able to see how callPoint is mapped by looking at the mappings in 20160806 index. Using Sense
GET 20160806
If the mapping for callPoint is { "type" : "string" } then the input will be analyzed at index time. You can see how the standard analyzer will analyze the input using the _analyze API
POST _analyze
{
"text" : "/cloudconnect/api/xxxxxxx/v1",
"analyzer": "standard"
}
produces the following tokens
{
"tokens": [
{
"token": "cloudconnect",
"start_offset": 1,
"end_offset": 13,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "api",
"start_offset": 14,
"end_offset": 17,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "xxxxxxx",
"start_offset": 18,
"end_offset": 25,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "v1",
"start_offset": 26,
"end_offset": 28,
"type": "<ALPHANUM>",
"position": 3
}
]
}
A term query does not analyze the query input so will be attempting to match the query input as is against what is in the inverted index, which for the callPoint field, has been analyzed at index time. A match query does analyze the query input so you would get a match for the document as expected. Alternatively, you could map callPoint as a not_analyzed string field so that the input is not analyzed at index time and is indexed verbatim.