Skip to content

Commit fcc509a

Browse files
authored
Update search-howto-index-one-to-many-blobs.md
1 parent d888e70 commit fcc509a

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

articles/search/search-howto-index-one-to-many-blobs.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -132,9 +132,9 @@ id, temperature, pressure, timestamp
132132
2, 120, 3,"2013-05-11T00:00:00Z"
133133
```
134134

135-
Notice that each document contains the `id` field, which is defined as the 'key' field in the index. In such a case, even though a document-unique `AzureSearch_DocumentKey` will be generated, it won't be used as the 'key' for the document. Rather, the value of the `id` field will be mapped to the 'key' field
135+
Notice that each document contains the `id` field, which is defined as the "key" field in the index. In such a case, even though a document-unique `AzureSearch_DocumentKey` will be generated, it won't be used as the "key" for the document. Rather, the value of the `id` field will be mapped to the "key" field
136136

137-
Similar to the example above, this mapping will _not_ result in 4 documents showing up in the index, because the `id` field is not unique _across blobs_. When this is the case, any json entry that specifies an `id` will result in a merge on the existing document instead of an upload of a new document, and the state of the index will reflect the latest read entry with the specified `id`.
137+
Similar to the example above, this mapping will _not_ result in four documents showing up in the index, because the `id` field is not unique _across blobs_. When this is the case, any json entry that specifies an `id` will result in a merge on the existing document instead of an upload of a new document, and the state of the index will reflect the latest read entry with the specified `id`.
138138

139139
## Next steps
140140

0 commit comments

Comments
 (0)