@@ -70,9 +70,9 @@ GET my-index-000001/_search
70
70
71
71
It's possible for conflicting names to arise, for fields that are defined within different scopes:
72
72
73
- 1 . A pass-through object is defined next to a field that has the same name as one of the pass-through object
74
- sub-fields, e.g.
75
-
73
+ a . A pass-through object is defined next to a field that has the same name as one of the pass-through object
74
+ sub-fields, e.g.
75
+ +
76
76
[source,console]
77
77
--------------------------------------------------
78
78
PUT my-index-000001/_doc/1
@@ -83,12 +83,12 @@ PUT my-index-000001/_doc/1
83
83
"id": "bar"
84
84
}
85
85
--------------------------------------------------
86
+ +
87
+ In this case, references to `id` point to the field at the root level, while field `attributes.id`
88
+ can only be accessed using the full path.
86
89
87
- In this case, references to `id` point to the field at the root level, while field `attributes.id`
88
- can only be accessed using the full path.
89
-
90
- 1. Two (or more) pass-through objects are defined within the same object and contain fields with the same name, e.g.
91
-
90
+ b. Two (or more) pass-through objects are defined within the same object and contain fields with the same name, e.g.
91
+ +
92
92
[source,console]
93
93
--------------------------------------------------
94
94
PUT my-index-000002
@@ -117,7 +117,7 @@ PUT my-index-000002
117
117
}
118
118
}
119
119
--------------------------------------------------
120
-
120
+ +
121
121
In this case, param `priority` is used for conflict resolution, with the higher values taking precedence. In the
122
122
example above, `resource.attributes` has higher priority than `attributes`, so references to `id` point to the field
123
123
within `resource.attributes`. `attributes.id` can still be accessed using its full path.
0 commit comments