-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Add Azure.Core JsonPatchDocument to DigitalTwins project to replace UpdateOperationsUtility #16129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| <Project Sdk="Microsoft.NET.Sdk"> | ||
| <Project Sdk="Microsoft.NET.Sdk"> | ||
| <!-- Assembly props --> | ||
| <PropertyGroup> | ||
| <AssemblyTitle>Digital Twins SDK</AssemblyTitle> | ||
|
|
@@ -51,5 +51,17 @@ | |
| </Compile> | ||
| </ItemGroup> | ||
|
|
||
| <Import Project="$(RepoRoot)\sdk\core\Azure.Core\src\Azure.Core.props" /> | ||
| <!-- | ||
| This project currently takes a project reference on Azure.Core, rather than deferring to Azure.Core.props to choose between project reference and nuget reference. | ||
| This is because the project needs access to the JsonPatchDocument type that is defined in Azure.Core, but has not been released in a nuget yet. After the next | ||
| release of Azure.Core, the below can be changed back so that we just import Azure.Core.props | ||
| --> | ||
|
|
||
| <!--Uncomment the below to take reference from Azure.Core based on how Azure.Core.props defines how libraries should take reference--> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you elaborate on the problem here?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can add more comments to the code itself, too, but the issue here is that the Azure.Core library hasn't had a release since they added the JsonPatchDocument class. So the only way we'll get access to it is to take a project reference instead. This all becomes moot if we don't want the JsonPatchDocument in our API shape, though
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha. Might put it in those words as the existing comment didn't make sense to me. |
||
| <!--<Import Project="$(RepoRoot)\sdk\core\Azure.Core\src\Azure.Core.props" />--> | ||
|
|
||
| <!--Remove the below after uncommenting the above in order to stop taking a project reference on Azure.Core--> | ||
| <ItemGroup> | ||
| <ProjectReference Include="..\..\..\core\Azure.Core\src\Azure.Core.csproj" /> | ||
| </ItemGroup> | ||
| </Project> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious we chose to require this specific data type, rather than a string that has json. My reasoning being that a customer wanted to use their own library, they can't do that now. Thoughts?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a fair point. I can revert these APIs back to taking strings rather than the JsonPatchDocument itself for now. I'll add a note in our board review to talk about this furtherScratch that, the JsonPatchDocument class allows for users to set their own ObjectSerializer, so this isn't an issue. I'd still like to use this class directly in our APIs, especially if we are getting away from representing untyped json as strings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend leaving the way you have it for now, reach out to Krzysztof directly for direction advice, and then mention it in the board review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drwill-ms just in case you signed off thinking I would revert the API shape back to taking a string. Thoughts on taking the JsonPatchDocument knowing that it takes an ObjectSerializer that allows for users to provide their favorite json library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, I didn't sign off with that understanding. I'd have been more explicit if that were the case.