Updated @azure/cosmos version to 3.17.3-beta.1 #25007
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
v1k1
requested review from
kushagraThapar,
kirankumarkolli and
abkolant-MSFT
as code owners
ghost
added
the
|
/azp run js - cosmosdb - ci |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
API change check APIView has identified API level changes in this PR and created following API reviews. |
v1k1
added a commit
to v1k1/azure-sdk-for-js
that referenced
this pull request
Apr 3, 2023
Packages impacted by this PR @azure/cosmos Issues associated with this PR Describe the problem that is addressed by this PR Added Hierarchical Partition Key Support Refactored Definition of PartitionKey. Old definition - type PartitionKey = PartitionKeyDefinition | string | number | unknown; New definition - type PartitionKey = PrimitivePartitionKeyValue | PrimitivePartitionKeyValue[]; The main change here is a) Separating out PartitionKeyDefinition [May seem like a breaking change. But the actual functions which need PartitionKeyDefinition were always taking PartitionKeyDefinition as an input i.e. ContainerDefinition, the existing definition seems confusing.] b) Removal of unknown from definition (along with adding boolean). Defining it as PartitionKeyDefinition | string | number | unknown was effectively equivalent to unknown, since or of anything with unknown is unknown. Which essentially means we had no structure upon PartitionKey. This seems like a huge bug. Introduced PartitionKeyInternal to create a boundary beyond with PartitionKey would be sanitized. The idea is to use ClientContext as that boundary. Changed bulk/batch api Operation/OperationInput DTOs partitionKey field to PartitionKey type. Clearly defined order for choosing partitionKey for an operation during bulk api. Now if the user has provided partitionKey in OperationInput it will be used, if not it will be derived from resource body (for create and upsert). Added logic for MultiHash calculation. Changed FeedOption.partitionKey filed to PartitionKey type. [[Bugs fixes]] In bulk api, The case when partition key path has escaped characters was not handled. In batch.ts -> deepFind() method. In bulk/batch api Operation/OperationInput DTOs were inconsistent in supporting type of partition key values. What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen? Are there test cases added in this PR? (If not, why?) Yes Provide a list of related PRs (if any) Command used to generate this PR:**(Applicable only to SDK release request PRs) Checklists Added impacted package name to the issue description Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here) Added a changelog (if necessary)
v1k1
added a commit
to v1k1/azure-sdk-for-js
that referenced
this pull request
Jun 7, 2023
Packages impacted by this PR @azure/cosmos Issues associated with this PR Describe the problem that is addressed by this PR Added Hierarchical Partition Key Support Refactored Definition of PartitionKey. Old definition - type PartitionKey = PartitionKeyDefinition | string | number | unknown; New definition - type PartitionKey = PrimitivePartitionKeyValue | PrimitivePartitionKeyValue[]; The main change here is a) Separating out PartitionKeyDefinition [May seem like a breaking change. But the actual functions which need PartitionKeyDefinition were always taking PartitionKeyDefinition as an input i.e. ContainerDefinition, the existing definition seems confusing.] b) Removal of unknown from definition (along with adding boolean). Defining it as PartitionKeyDefinition | string | number | unknown was effectively equivalent to unknown, since or of anything with unknown is unknown. Which essentially means we had no structure upon PartitionKey. This seems like a huge bug. Introduced PartitionKeyInternal to create a boundary beyond with PartitionKey would be sanitized. The idea is to use ClientContext as that boundary. Changed bulk/batch api Operation/OperationInput DTOs partitionKey field to PartitionKey type. Clearly defined order for choosing partitionKey for an operation during bulk api. Now if the user has provided partitionKey in OperationInput it will be used, if not it will be derived from resource body (for create and upsert). Added logic for MultiHash calculation. Changed FeedOption.partitionKey filed to PartitionKey type. [[Bugs fixes]] In bulk api, The case when partition key path has escaped characters was not handled. In batch.ts -> deepFind() method. In bulk/batch api Operation/OperationInput DTOs were inconsistent in supporting type of partition key values. What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen? Are there test cases added in this PR? (If not, why?) Yes Provide a list of related PRs (if any) Command used to generate this PR:**(Applicable only to SDK release request PRs) Checklists Added impacted package name to the issue description Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here) Added a changelog (if necessary)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Packages impacted by this PR
Issues associated with this PR
Describe the problem that is addressed by this PR
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists