The script clears the indices and sets up dynamic mapping so that all child
documents are treated as nested.
Then there are two queries on fields of message.statistics.timings.measure.thing.
The first, on uniqueThing field succeeds.
The second on the id field fails with zero documents.
Not sure why the second query is failing to locate any documents.
Could anyone help please? We're kind of stuck right now - trying to get to
a point that we demonstrate ES working for our use-cases to get management
blessing.
thanks
Fuzz.
On Tuesday, 24 June 2014 14:43:01 UTC+1, dazraf wrote:
The script clears the indices and sets up dynamic mapping so that all
child documents are treated as nested.
Then there are two queries on fields of message.statistics.timings.measure.thing.
The first, on uniqueThing field succeeds.
The second on the id field fails with zero documents.
Not sure why the second query is failing to locate any documents.
The script clears the indices and sets up dynamic mapping so that all
child documents are treated as nested.
Then there are two queries on fields of message.statistics.timings.measure.thing.
The first, on uniqueThing field succeeds.
The second on the id field fails with zero documents.
Not sure why the second query is failing to locate any documents.
It is not related to that issue. In that issue, your query would work, but
all the nested documents are returned, not just the relevant.
It seems like the query fails on fields named "id". If you rename that
field, the query works, so it has nothing to do with your mapping. I would
report it as a bug or use another field name.
The script clears the indices and sets up dynamic mapping so that all
child documents are treated as nested.
Then there are two queries on fields of message.statistics.timings.measure.thing.
The first, on uniqueThing field succeeds.
The second on the id field fails with zero documents.
Not sure why the second query is failing to locate any documents.
Thanks very much for the response! It's great to know you're able to
reproduce the use-case.
Although one can always write custom mappings or change the client, our aim
is to:
Avoid using schema-specific mappings; and
Avoid forcing the clients with any schema constraints
Querying/filtering by a nested "id" field should be supported as any other
field I think - seeing that the documents do not preclude this use.
Therefore, perhaps its reasonable to raise a bug report and see it fixed.
Would you agree?
many thanks and kind regards,
Fuzz.
On Friday, 27 June 2014 21:16:24 UTC+1, Ivan Brusic wrote:
It is not related to that issue. In that issue, your query would work, but
all the nested documents are returned, not just the relevant.
It seems like the query fails on fields named "id". If you rename that
field, the query works, so it has nothing to do with your mapping. I would
report it as a bug or use another field name.
The script clears the indices and sets up dynamic mapping so that all
child documents are treated as nested.
Then there are two queries on fields of message.statistics.timings.measure.thing.
The first, on uniqueThing field succeeds.
The second on the id field fails with zero documents.
Not sure why the second query is failing to locate any documents.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.