honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/query-dsl/parent-id-query.asciidoc

56 lines
1.4 KiB
Plaintext
Raw Normal View History

Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
[[query-dsl-parent-id-query]]
=== Parent Id Query
Bump Elasticsearch version to 5.0.0-SNAPSHOT This commit bumps the Elasticsearch version to 5.0.0-SNAPSHOT in line with the alignment of versions across the stack. Closes #16862
2016-02-29 10:21:39 -05:00
added[5.0.0]
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
The `parent_id` query can be used to find child documents which belong to a particular parent:
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
[source,js]
--------------------------------------------------
Convert rest of query-dsl docs to be run in tests
2016-05-11 08:37:19 -04:00
PUT /my_index
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
{
Adds ignore_unmapped option to nested and P/C queries The change adds a new option to the `nested`, `has_parent`, `has_children` and `parent_id` queries: `ignore_unmapped`. If this option is set to false, the `toQuery` method on the QueryBuilder will throw an exception if the type/path specified in the query is unmapped. If the option is set to true, the `toQuery` method on the QueryBuilder will return a MatchNoDocsQuery. The default value is `false`so the queries work how they do today (throwing an exception on unmapped paths/types)
2016-04-14 04:37:18 -04:00
"parent_id" : {
"type" : "blog_tag",
"id" : "1"
}
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
}
--------------------------------------------------
Convert rest of query-dsl docs to be run in tests
2016-05-11 08:37:19 -04:00
// CONSOLE
// TESTSETUP
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
The above is functionally equivalent to using the following
<<query-dsl-has-parent-query, `has_parent`>> query, but performs
better as it does not need to do a join:
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
[source,js]
--------------------------------------------------
Convert rest of query-dsl docs to be run in tests
2016-05-11 08:37:19 -04:00
GET /_search
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
{
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
"query": {
Convert rest of query-dsl docs to be run in tests
2016-05-11 08:37:19 -04:00
"has_parent": {
"type": "blog",
"query": {
"term": {
"_id": "1"
}
}
}
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
}
}
--------------------------------------------------
Convert rest of query-dsl docs to be run in tests
2016-05-11 08:37:19 -04:00
// CONSOLE
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
==== Parameters
This query has two required parameters:
[horizontal]
Docs: Clarified the purpose of the parent_id query
2016-04-14 05:25:26 -04:00
`type`:: The **child** type. This must be a type with `_parent` field.
Cleanup ParentFieldMapper: * Remove remaining 1.x bwc logic. * Stop storing stored fields and indexed terms. The _parent field's only purpose is to support joins between parent and child type and only storing doc values is sufficient. * In the mapping the parent field mapper is now known under '{parent}#{child}' key, because this is the field the parent/child join uses too. * Added new sub fetch phase to lookup that _parent field from doc values field if that is required (before this was fetched from stored _parent field) * Removed the ability to query directly on `_parent` in the query dsl. Instead the `{parent}#{child}` field should be used. Under the hood a doc values query is used instead of a term query, because only doc values fields are stored now. * Added a new `parent_id` query to easily query child documents with a specific parent id without having to know what join field to use * Also in aggregations `_parent` field can't be used any more and `{parent}#{child}` field name should be used instead to aggregate directly on the _parent join field.
2016-01-17 16:49:07 -05:00
Adds ignore_unmapped option to nested and P/C queries The change adds a new option to the `nested`, `has_parent`, `has_children` and `parent_id` queries: `ignore_unmapped`. If this option is set to false, the `toQuery` method on the QueryBuilder will throw an exception if the type/path specified in the query is unmapped. If the option is set to true, the `toQuery` method on the QueryBuilder will return a MatchNoDocsQuery. The default value is `false`so the queries work how they do today (throwing an exception on unmapped paths/types)
2016-04-14 04:37:18 -04:00
`id`:: The required parent id select documents must referrer to.
`ignore_unmapped`:: When set to `true` this will ignore an unmapped `type` and will not match any
documents for this query. This can be useful when querying multiple indexes
which might have different mappings. When set to `false` (the default value)
the query will throw an exception if the `type` is not mapped.