You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/search/cognitive-search-incremental-indexing-conceptual.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.service: azure-ai-search
8
8
ms.custom:
9
9
- ignite-2023
10
10
ms.topic: conceptual
11
-
ms.date: 06/25/2024
11
+
ms.date: 01/17/2025
12
12
---
13
13
14
14
# Incremental enrichment and caching in Azure AI Search
@@ -40,7 +40,7 @@ The following example illustrates an indexer with caching enabled. See [Enable e
40
40
To use the cache property, you can use 2020-06-30-preview or later when you [create or update an indexer](/rest/api/searchservice/indexers/create-or-update?view=rest-searchservice-2024-05-01-preview&preserve-view=true). We recommend the latest preview API.
41
41
42
42
```json
43
-
POST https://[search service name].search.windows.net/indexers?api-version=2024-05-01-rreview
43
+
POST https://[YOUR-SEARCH-SERVICE-NAME].search.windows.net/indexers?api-version=2024-05-01-preview
Copy file name to clipboardExpand all lines: articles/search/index-sql-relational-data.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,16 +9,16 @@ ms.service: azure-ai-search
9
9
ms.custom:
10
10
- ignite-2023
11
11
ms.topic: how-to
12
-
ms.date: 03/18/2024
12
+
ms.date: 01/18/2025
13
13
---
14
14
15
15
# How to model relational SQL data for import and indexing in Azure AI Search
16
16
17
-
Azure AI Search accepts a flat rowset as input to the [indexing pipeline](search-what-is-an-index.md). If your source data originates from joined tables in a SQL Server relational database, this article explains how to construct the result set, and how to model a parent-child relationship in an Azure AI Search index.
17
+
Azure AI Search accepts a flat rowset as input to the [indexing pipeline](search-what-is-an-index.md). If your source data originates from joined tables in a SQL Server relational database, this article explains how to construct the rowset, and how to model a parent-child relationship in an Azure AI Search index.
18
18
19
19
As an illustration, we refer to a hypothetical hotels database, based on [demo data](https://github.com/Azure-Samples/azure-search-sample-data/tree/main/hotels). Assume the database consists of a `Hotels$` table with 50 hotels, and a `Rooms$` table with rooms of varying types, rates, and amenities, for a total of 750 rooms. There's a one-to-many relationship between the tables. In our approach, a view provides the query that returns 50 rows, one row per hotel, with associated room detail embedded into each row.
20
20
21
-
![Tables and view in the Hotels database](media/index-sql-relational-data/hotels-database-tables-view.png"Tables and view in the Hotels database")
21
+
![Tables and view in the Hotels database](media/index-sql-relational-data/hotels-database-tables-view.png"Screenshot of tables and view in the Hotels database.")
22
22
23
23
## The problem of denormalized data
24
24
@@ -32,9 +32,9 @@ ON Rooms$.HotelID = Hotels$.HotelID
32
32
33
33
Results from this query return all of the Hotel fields, followed by all Room fields, with preliminary hotel information repeating for each room value.
34
34
35
-
![Denormalized data, redundant hotel data when room fields are added](media/index-sql-relational-data/denormalize-data-query.png"Denormalized data, redundant hotel data when room fields are added")
35
+
![Denormalized data, redundant hotel data when room fields are added](media/index-sql-relational-data/denormalize-data-query.png"Screenshot of denormalized data, redundant hotel data when room fields are added.")
36
36
37
-
While this query succeeds on the surface (providing all of the data in a flat row set), it fails in delivering the right document structure for the expected search experience. During indexing, Azure AI Search creates one search document for each row ingested. If your search documents looked like the above results, you would have perceived duplicates - seven separate documents for the Old Century Hotel alone. A query on "hotels in Florida" would return seven results for just the Old Century Hotel, pushing other relevant hotels deep into the search results.
37
+
While this query succeeds on the surface (providing all of the data in a flat rowset), it fails in delivering the right document structure for the expected search experience. During indexing, Azure AI Search creates one search document for each row ingested. If your search documents looked like the above results, you would have perceived duplicates - seven separate documents for the Old Century Hotel alone. A query on "hotels in Florida" would return seven results for just the Old Century Hotel, pushing other relevant hotels deep into the search results.
38
38
39
39
To get the expected experience of one document per hotel, you should provide a rowset at the right granularity, but with complete information. This article explains how.
40
40
@@ -94,11 +94,11 @@ The solution is to capture the room detail as nested JSON, and then insert the J
94
94
95
95
The following screenshot shows the resulting view, with the *Rooms* nvarchar field at the bottom. The *Rooms* field exists only in the HotelRooms view.
![HotelRooms view](media/index-sql-relational-data/hotelsrooms-view.png"Screenshot of the HotelRooms view.")
98
98
99
99
1. Run `SELECT * FROM dbo.HotelRooms` to retrieve the row set. This query returns 50 rows, one per hotel, with associated room information as a JSON collection.
100
100
101
-
![Rowset from HotelRooms view](media/index-sql-relational-data/hotelrooms-rowset.png"Rowset from HotelRooms view")
101
+
![Rowset from HotelRooms view](media/index-sql-relational-data/hotelrooms-rowset.png"Screenshot of the rowset from the HotelRooms view.")
102
102
103
103
This rowset is now ready for import into Azure AI Search.
104
104
@@ -159,7 +159,7 @@ As noted in [Model complex types](search-howto-complex-data-types.md): "the docu
159
159
160
160
Using your own data set, you can use the [Import data wizard](search-import-data-portal.md) to create and load the index. The wizard detects the embedded JSON collection, such as the one contained in *Rooms*, and infers an index schema that includes a complex type collection.
161
161
162
-
162
+
163
163
164
164
Try the following quickstart to learn the basic steps of the Import data wizard.
Copy file name to clipboardExpand all lines: articles/search/search-howto-index-one-to-many-blobs.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.service: azure-ai-search
11
11
ms.custom:
12
12
- ignite-2023
13
13
ms.topic: conceptual
14
-
ms.date: 01/18/2024
14
+
ms.date: 01/18/2025
15
15
---
16
16
17
17
# Indexing blobs and files to produce multiple search documents
@@ -105,12 +105,12 @@ When you create an indexer with `delimitedText` **parsingMode**, it might feel n
105
105
}
106
106
```
107
107
108
-
However, this mapping won't result in four documents showing up in the index because the `recordid` field isn't unique _across blobs_. Hence, we recommend you to make use of the implicit field mapping applied from the `AzureSearch_DocumentKey` property to the key index field for "one-to-many" parsing modes.
108
+
However, this mapping doesn't result in four documents showing up in the index because the `recordid` field isn't unique _across blobs_. Hence, we recommend you to make use of the implicit field mapping applied from the `AzureSearch_DocumentKey` property to the key index field for "one-to-many" parsing modes.
109
109
110
110
If you do want to set up an explicit field mapping, make sure that the _sourceField_ is distinct for each individual entity **across all blobs**.
111
111
112
112
> [!NOTE]
113
-
> The approach used by `AzureSearch_DocumentKey` of ensuring uniqueness per extracted entity is subject to change and therefore you should not rely on it's value for your application's needs.
113
+
> The approach used by `AzureSearch_DocumentKey` of ensuring uniqueness per extracted entity is subject to change and therefore you shouldn't rely on its value for your application's needs.
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`is generated, it isn't used as the "key" for the document. Rather, the value of the `id` field is mapped to the `key` field
136
136
137
-
Similar to the previous example, this mapping won't result in four documents showing up in the index because the `id` field isn't 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 previous example, this mapping doesn't result in four documents showing up in the index because the `id` field isn't unique _across blobs_. When this is the case, any json entry that specifies an `id`results in a merge on the existing document instead of an upload of a new document, and the state of the index reflects the latest read entry with the specified `id`.
0 commit comments