|
1 | 1 | # Release History |
2 | 2 |
|
3 | 3 | ## 4.0.0 (2023-09-12) |
| 4 | +🎉 v4 release! 🎉 Many new features, bug fixes, and a few breaking changes. |
| 5 | +- Summary of new added features |
| 6 | + - Diagnostics: A diagnostic object has been added to responses of api operations ie. point lookups, bulk & batch operations, query and error responses, which contains information related to metadata lookups, retries, request and reponse latencies and payload siezes. |
| 7 | + - Hierarchical Partitioning: Containers with hierarchical partitions are now supported. [docs](https://learn.microsoft.com/azure/cosmos-db/hierarchical-partition-keys) |
| 8 | + - Index metrics: can be enabled to show both utilized indexed paths and recommended indexed paths. [docs](https://learn.microsoft.com/azure/cosmos-db/nosql/index-metrics?tabs=javascript) |
| 9 | + - New Changefeed iterator: which can consume changes for a specific partition key, a feed range or an entire container. [docs](https://learn.microsoft.com/azure/cosmos-db/nosql/change-feed-pull-model?tabs=JavaScript) |
| 10 | + - Priority based throttling is now supported. [docs](https://devblogs.microsoft.com/cosmosdb/introducing-priority-based-execution-in-azure-cosmos-db-preview/) |
| 11 | + |
| 12 | +### New Features |
| 13 | + |
| 14 | +#### Diagnostics |
| 15 | +- Since `diagnostics` is added to all Response objects. You could programatically access `CosmosDiagnostic` as follows. |
| 16 | +```js |
| 17 | + // For point look up operations |
| 18 | + const { container, diagnostics: containerCreateDiagnostic } = |
| 19 | + await database.containers.createIfNotExists({ |
| 20 | + id: containerId, |
| 21 | + partitionKey: { |
| 22 | + paths: ["/key1"], |
| 23 | + }, |
| 24 | + }); |
| 25 | + |
| 26 | + // For Batch operations |
| 27 | + const operations: OperationInput[] = [ |
| 28 | + { |
| 29 | + operationType: BulkOperationType.Create, |
| 30 | + resourceBody: { id: 'A', key: "A", school: "high" }, |
| 31 | + }, |
| 32 | + ]; |
| 33 | + const response = await container.items.batch(operations, "A"); |
| 34 | + const diagnostics = response.diagnostics |
| 35 | + |
| 36 | + // For Bulk operations |
| 37 | + const operations: OperationInput[] = [ |
| 38 | + { |
| 39 | + operationType: BulkOperationType.Create, |
| 40 | + resourceBody: { id: 'A', key: "A", school: "high" }, |
| 41 | + }, |
| 42 | + ]; |
| 43 | + const response = await container.items.bulk(operations);; |
| 44 | + const diagnostics = response.diagnostics |
| 45 | + |
| 46 | + // For query operations |
| 47 | + const queryIterator = container.items.query("select * from c"); |
| 48 | + const { resources, diagnostics } = await queryIterator.fetchAll(); |
| 49 | + |
| 50 | + // While error handling |
| 51 | + try { |
| 52 | + // Some operation that might fail |
| 53 | + } catch (err) { |
| 54 | + const diagnostics = err.diagnostics |
| 55 | + } |
| 56 | +``` |
| 57 | +#### Hierarchical Partitioning |
| 58 | +- Here is a sampele for creating container with Hierarchical Partitions |
| 59 | + |
| 60 | + ```js |
| 61 | + const containerDefinition = { |
| 62 | + id: "Test Database", |
| 63 | + partitionKey: { |
| 64 | + paths: ["/name", "/address/zip"], |
| 65 | + version: PartitionKeyDefinitionVersion.V2, |
| 66 | + kind: PartitionKeyKind.MultiHash, |
| 67 | + }, |
| 68 | + } |
| 69 | + const { container } = await database.containers.createIfNotExists(containerDefinition); |
| 70 | + console.log(container.id); |
| 71 | + ``` |
| 72 | +- Definition of PartitionKey has been changed to support Hierarchical partitioning. Here is how to use the new definition. |
| 73 | + - The operations for which PartitionKey can be derived from Request body, providing PartitionKey is optional as always i.e |
| 74 | + ```js |
| 75 | + const item = { |
| 76 | + id: 1, |
| 77 | + name: 'foo', |
| 78 | + address: { |
| 79 | + zip: 100 |
| 80 | + }, |
| 81 | + active: true |
| 82 | + } |
| 83 | + await container.items.create(item); |
| 84 | + ``` |
| 85 | + - Here is sample for operations which require hierarchical partition to be passed. |
| 86 | + |
| 87 | + ```js |
| 88 | + await container.item("1", ["foo", 100]).read(); |
| 89 | + ``` |
| 90 | + OR |
| 91 | + ```js |
| 92 | + const partitionKey: PartitionKey = new PartitionKeyBuilder() |
| 93 | + .addValue("foo") |
| 94 | + .addValue(100) |
| 95 | + .build(); |
| 96 | + await container.item("1", partitionKey).read(); |
| 97 | + ``` |
| 98 | + - If you are not using Hierarchical Partitioning feature, Definition of Partition Key is practically backward compatible. |
| 99 | + ```js |
| 100 | + await container.item("1", "1").read(); |
| 101 | + ``` |
| 102 | + |
| 103 | +#### New Change feed Iterator |
| 104 | + |
| 105 | +The v4 SDK now supports [Change feed pull model](https://learn.microsoft.com/azure/cosmos-db/nosql/change-feed-pull-model?tabs=JavaScript). |
| 106 | + |
| 107 | +***Note: There are no breaking changes, the old change feed iterator is still supported.*** |
| 108 | + |
| 109 | +Major Differences: |
| 110 | +- The new iterator allows fetching change feed for a partition key, a feed range, or an entire container, compared to the older iterator, which was limited to fetching change feed for a partition key only. |
| 111 | + |
| 112 | +- The new implementation is effectively an infinite list of items that encompasses all future writes and updates. The `hasMoreResults` property now always returns `true`, unlike the older implementation, which returned `false` when a `NotModified` status code was received from the backend. |
| 113 | + |
| 114 | +Here is an example of creating and using the new change feed iterator: |
| 115 | +```js |
| 116 | +const changeFeedOptions = { |
| 117 | + changeFeedStartFrom : ChangeFeedStartFrom.Beginning("partition key or feed range"), |
| 118 | + maxItemCount: 10 |
| 119 | +} |
| 120 | +const iterator = container.items.getChangeFeedIterator(changeFeedOptions); |
| 121 | +while(iterator.hasMoreResults) { |
| 122 | + const res = await iterator.readNext(); |
| 123 | + // process res |
| 124 | +} |
| 125 | +``` |
| 126 | +#### Index Metrics [#20194](https://github.com/Azure/azure-sdk-for-js/issues/20194) |
| 127 | + |
| 128 | +Azure Cosmos DB provides indexing metrics for optimizing query performance, especially when you're unsure about adjusting the indexing policy. |
| 129 | +You can enable indexing metrics for a query by setting the PopulateIndexMetrics property to true(default=false). |
| 130 | +
|
| 131 | +```js |
| 132 | +const { resources: resultsIndexMetrics, indexMetrics } = await container.items |
| 133 | + .query(querySpec, { populateIndexMetrics: true }) |
| 134 | + .fetchAll(); |
| 135 | +``` |
| 136 | +
|
| 137 | +We only recommend enabling the index metrics for troubleshooting query performance. |
| 138 | +
|
| 139 | +#### Enhanced Retry Utility for Improved SDK Reliability [#23475](https://github.com/Azure/azure-sdk-for-js/issues/23475) |
| 140 | +
|
| 141 | +Improved the retry utility to align with other language SDKs. Now, it automatically retries requests on the next available region when encountering HTTP 503 errors (Service Unavailable) |
| 142 | +and handles HTTP timeouts more effectively, enhancing the SDK's reliability. |
| 143 | + |
| 144 | +#### Priority based throttling [docs](https://devblogs.microsoft.com/cosmosdb/introducing-priority-based-execution-in-azure-cosmos-db-preview/) [#26393](https://github.com/Azure/azure-sdk-for-js/pull/26393/files) |
| 145 | + |
| 146 | +Priority-based execution is a capability which allows users to specify priority for the request sent to Azure Cosmos DB. Based on the priority specified by the user, if there are more requests than the configured RU/s in a second, then Azure Cosmos DB will throttle low priority requests to allow high priority requests to execute. |
| 147 | +You can enable priority based throttling by setting priorityLevel property. |
| 148 | + |
| 149 | +```js |
| 150 | +const response = await container.item(document.id).read<TestItem>({ priorityLevel: PriorityLevel.Low }); |
| 151 | +``` |
4 | 152 |
|
5 | | -### Features Added |
6 | | -- Added Changefeed support for partition keys, feed ranges, and entire container. [#18062](https://github.com/Azure/azure-sdk-for-js/issues/18062) |
7 | | -- Added Diagnostics to all response objects, i.e. ResourceResponse (parent class for ItemRespone, ContainerResponse etc.), FeedResponse, ChangeFeedIteratorResponse, |
8 | | -ErrorResponse, BulkOperationResponse. [#21177](https://github.com/Azure/azure-sdk-for-js/issues/21177) |
9 | | -- Added support for hierarchical partitions. [#23416](https://github.com/Azure/azure-sdk-for-js/issues/23416) |
10 | | -- Added support of index metrics. [#20194](https://github.com/Azure/azure-sdk-for-js/issues/20194) |
11 | | -- Improved the retry utility to align with other language SDKs. Now, it automatically retries requests on the next available region when encountering HTTP 503 errors (Service Unavailable) |
12 | | - and handles HTTP timeouts more effectively, enhancing the SDK's reliability. [#23475](https://github.com/Azure/azure-sdk-for-js/issues/23475) |
13 | | -- Added priority based throttling. [docs](https://devblogs.microsoft.com/cosmosdb/introducing-priority-based-execution-in-azure-cosmos-db-preview/) [#26393](https://github.com/Azure/azure-sdk-for-js/pull/26393/files) |
14 | 153 | ### Bugs Fixed |
15 | 154 | - Updated response codes for the getDatabase() method. [#25932](https://github.com/Azure/azure-sdk-for-js/issues/25932) |
16 | 155 | - Fix Upsert operation failing when partition key of container is `/id` and `/id` is missing in the document. [#21383](https://github.com/Azure/azure-sdk-for-js/issues/21383) |
|
0 commit comments