Why is `properties.` required in search terms

OpenSearch
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
AWS OpenSearch (not sure where to find the version)

Describe the issue:
Newbie question, sorry.

All documentation I’ve seen for posting a document involves nesting the terms in a properties object:

POST locations-b/_doc/
{
  "properties": {
    "zipcode" : "02134"
  }
}

The document indexes successfully, and a match_all query shows the doc. But if I go to search for it, this turns up 0 hits:

GET locations-b/_search
{
  "query": {
    "match": {"zipcode": "02134"}
  }
}

In order to get hits, I need to specify the properties “container” in the query. This does work:

GET locations-b/_search
{
  "query": {
    "match": {"properties.zipcode": "02134"}
  }
}

But none of the search examples in documentation show that properties. needs to be specified in the query.

Am I doing something wrong? Or is this a quirk of the AWS implementation? Is there way to set up a mask or something so that it’s always implied? Thanks for any suggestions.

Relevant Logs or Screenshots:

2

You don’t have to have “properties” when you index documents. Here’s an example from the docs: Popular APIs - OpenSearch documentation

You’ll need properties to define your fields in the mapping: Mappings and field types - OpenSearch documentation

In your example “properties” is an object (it could be anything, say “props” or “foo”). And then when you search in a field in this object you have to specify the “full path”. In your case properties.zipcode.

1 Like
3

Thanks Radu - Yes I did discover that after writing this question. Unfortunately there are a lot of tutorials and examples on the internet that show the indexing with a properties container to match the mapping. Goes to show you have to be skeptical about third-party tutorials sometimes. Cheers.

1 Like