Search inside field with nested array


(Svet) #1

Hi,

I am slowly becoming ES-addicted :-). However after reading the list
archive still can't figure out the following. My document has title
and tags in two languages. The title is like this:

"title": {
"es": "Spanish Title",
"en": "English Title"
}

And search with query_string finds it ok. However if I use array at
the nested level:

"tags": {
"es": [
"tag1",
"tag2",
"tag3"
],
"en": [
"etag1",
"etag2",
"etag3"
]
}

can´t figure out how to search for, say, "tag1". I've tried using
something as tags.es and tags.eu as name files without success even
when title.es does work.

What I am missing?


(Clinton Gormley) #2

Hiya

And search with query_string finds it ok. However if I use array at
the nested level:

"tags": {
"es": [
"tag1",
"tag2",
"tag3"
],
"en": [
"etag1",
"etag2",
"etag3"
]
}

can´t figure out how to search for, say, "tag1". I've tried using
something as tags.es and tags.eu as name files without success even
when title.es does work.

I assume you mean tags.en, not tags.eu. As I understand it, this should
work.

Can you gist a curl recreation of the problem?

thanks

clint


(Svet) #3

Hi, thank you for the fast answer! It is strange but I can't reproduce
it exactly in a new index. It seems that the problem is related to
having
documents with different structure inside the same type. Is this (not)
allowed?

For example:

  1. curl -XPUT 'http://localhost:9200/nestedtest/news/1' -d '{"title":
    {"es": "Primer Titulo", "en": "First Title"}, "tags": {"es":
    ["s1","s2"], "en": ["e1", "e2"]} }'
  2. curl -XPUT 'http://localhost:9200/nestedtest/news/2' -d '{"title":
    {"es": "Segundo Titulo", "en": "Second Title"}, "tags": {"es":
    ["s3","s4"], "en": ["e3", "e4"]} }'

now the following PUT returns
ReplicationShardOperationFailedException:

  1. curl -XPUT 'http://localhost:9200/nestedtest/news/3' -d '{"title":
    {"es": "Tercer Titulo", "en": "Third Title"}, "tags": ["s3", "s4"] }'

This doesn't work neither:

  1. curl -XPUT 'http://localhost:9200/nestedtest/news/4' -d '{"title":
    {"es": "Cuarto Titulo", "en": "Fourth Title"}, "tags": "just text this
    time" }'

However 3) and 4) does work in a new index, say nestedtest2 instead of
nestedtest.

Finally, if you start over and execute the PUTs in order 3),4),1),2)
all PUTs work.

On 20 ene, 11:27, Clinton Gormley clin...@iannounce.co.uk wrote:

Hiya

And search with query_string finds it ok. However if I use array at
the nested level:

"tags": {
"es": [
"tag1",
"tag2",
"tag3"
],
"en": [
"etag1",
"etag2",
"etag3"
]
}

can´t figure out how to search for, say, "tag1". I've tried using
something as tags.es and tags.eu as name files without success even
when title.es does work.

I assume you mean tags.en, not tags.eu. As I understand it, this should
work.

Can you gist a curl recreation of the problem?

thanks

clint


(Clinton Gormley) #4

On Thu, 2011-01-20 at 03:38 -0800, Svet wrote:

Hi, thank you for the fast answer! It is strange but I can't reproduce
it exactly in a new index. It seems that the problem is related to
having
documents with different structure inside the same type. Is this (not)
allowed?

All document types have a 'mapping' or type definition, which describes
how they should be indexed.

You can set this mapping manually, but if you don't, then ElasticSearch
will try to figure it out for you, based on the first time that it sees
each field.

Hence the confusion... :slight_smile:

clint


(Svet) #5

I see. Thank you! So, my next step is to learn about mapping :slight_smile:

On 20 ene, 13:11, Clinton Gormley clin...@iannounce.co.uk wrote:

On Thu, 2011-01-20 at 03:38 -0800, Svet wrote:

Hi, thank you for the fast answer! It is strange but I can't reproduce
it exactly in a new index. It seems that the problem is related to
having
documents with different structure inside the same type. Is this (not)
allowed?

All document types have a 'mapping' or type definition, which describes
how they should be indexed.

You can set this mapping manually, but if you don't, then ElasticSearch
will try to figure it out for you, based on the first time that it sees
each field.

Hence the confusion... :slight_smile:

clint


(system) #6