Disallow multiple parent-join fields per mapping #25002
Conversation
This change ensures that there is a single parent-join field defined per mapping. The verification is done through the addition of a special field mapper (MetaJoinFieldMapper) with a unique name (_parent_join) that is registered to the mapping service when the first parent-join field is defined. If a new parent-join is added, this field mapper will clash with the new one and the update will fail. This change also simplifies the parent join fetch sub phase by retrieving the parent-join field without iterating on all fields in the mapping.
|
\cc @jpountz |
martijnvg
left a comment
martijnvg
left a comment
There was a problem hiding this comment.
Left a question and a small comment. LGTM
| * Returns the {@link ParentJoinFieldMapper} associated with the <code>service</code> or null | ||
| * if there is no parent-join field in this mapping. | ||
| */ | ||
| public static ParentJoinFieldMapper getMapper(MapperService service) { |
There was a problem hiding this comment.
👍 (I added the same method here locally (differently implemented) )
| List<ParentIdFieldMapper> parentIdFields) { | ||
| super(simpleName, fieldType, Defaults.FIELD_TYPE, indexSettings, MultiFields.empty(), null); | ||
| this.parentIdFields = parentIdFields; | ||
| this.uniqueFieldMapper = uniqueFieldMapper; |
There was a problem hiding this comment.
should we also add uniqueFieldMapper.setFieldMapper(this) here ?
| return parentIdFields.stream().map((field) -> (Mapper) field).iterator(); | ||
| List<Mapper> mappers = new ArrayList<> (parentIdFields); | ||
| mappers.add(uniqueFieldMapper); | ||
| return mappers.iterator();//parentIdFields.stream().map((field) -> (Mapper) field).iterator(); |
jpountz
left a comment
jpountz
left a comment
There was a problem hiding this comment.
I think this is an ok hack for now, let's just make sure we revisit later, eg. the error message could be better.
|
Thanks @jpountz and @martijnvg
Yep, we also need to state clearly in the docs why it is forbidden. |
* master: (62 commits) Handle already closed while filling gaps [DOCS] Clarify behaviour of scripted-metric arg with empty parent buckets [DOCS] Clarify connections and gateway nodes selection in cross cluster search docs (elastic#24859) Java api: Remove unneeded getTookInMillis method (elastic#23923) Adds nodes usage API to monitor usages of actions (elastic#24169) Add superset size to Significant Term REST response (elastic#24865) Disallow multiple parent-join fields per mapping (elastic#25002) [Test] Remove unused test resources in core (elastic#25011) Scripting: Add optional context parameter to put stored script requests (elastic#25014) Extract a common base class for scroll executions (elastic#24979) Build: fix version sorting Build: Move verifyVersions to new branchConsistency task (elastic#25009) Add backwards compatibility indices Build: improve verifyVersions error message (elastic#25006) Add version 5.4.2 constant Docs: More search speed advices. (elastic#24802) Add version 5.3.3 constant Reorganize docs of global ordinals. (elastic#24982) Provide the TransportRequest during validation of a search context (elastic#24985) [TEST] fix SearchIT assertion to also accept took set to 0 ...
This change ensures that there is a single parent-join field defined per mapping. The verification is done through the addition of a special field mapper (MetaJoinFieldMapper) with a unique name (_parent_join) that is registered to the mapping service when the first parent-join field is defined. If a new parent-join is added, this field mapper will clash with the new one and the update will fail. This change also simplifies the parent join fetch sub phase by retrieving the parent-join field without iterating on all fields in the mapping.
This is a full backport of the typeless parent child feature (parent-join) introduced in master. It includes: * Introduce ParentJoinFieldMapper, a field mapper that creates parent/child relation within documents of the same index (#24978) * Disallow multiple parent-join fields per mapping (#25002) * Change `has_child`, `has_parent` queries and `childen` aggregation to work with the new join field type and at the same time maintaining support for the `_parent` meta field type. * Move parent_id query to the parent-join module (#25072) * Changed inner_hits to work with the new join field type and at the same time maintaining support for the `_parent` meta field type Relates #20257
|
If I'm interpreting the statement in the blog https://www.elastic.co/blog/this-week-in-elasticsearch-and-apache-lucene-2017-06-05 correctly:
Does this mean we can't have a parent with multiple child types anymore? What about nested parent-child relationships? |
|
No, it just means one join field can be configured per index. However a join field can be configured with multiple relations like you described above. |
clintongormley
added
the
:Search/Search
6 participants
This change ensures that there is a single parent-join field defined per mapping.
The verification is done through the addition of a special field mapper (MetaJoinFieldMapper) with a unique name (_parent_join) that is registered to the mapping service
when the first parent-join field is defined. If a new parent-join is added, this field mapper will clash with the new one and the update will fail.
This change also simplifies the parent join fetch sub phase by retrieving the parent-join field without iterating on all fields in the mapping.