GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||
GeezerVison is showing github.com — Refactor ConvertTo-Json to expose `JsonObject.ConvertToJson` as a public API by daxian-dbw · Pull Request #8682 · PowerShell/PowerShell Conversation
|
|
Dongbo Wang (@daxian-dbw) I see most of code is simply copy-pasted. It seems old code is not ideal - should we review line by line in depth or only new API? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Ilya (@iSazonov) This PR is purely a change on how code is organized, in order to expose the When reviewing the changes, I suggest to focus on the new APIs, how |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| targetCmdlet: this); | ||
|
|
||
| string output = JsonObject.ConvertToJson(objectToProcess, in context); | ||
| if (output != null) |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to check this?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I believe so. In case ctrl+c is signaled, JsonObject.ConvertToJson would return null, and I think we don't want to write that null to pipeline.
I know that when the pipeline is stopping, WriteObject will throw from MshCommandRuntime._WriteObjectSkipAllowCheck, so technically it might be OK to remove this check.
But I want to play safe here. What do you think?
For comparison, please take a look at the use of Stopping in the original code path where a StopException is thrown which results in return from EndProcessing.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I see that new code keep previous behavior and my thoughts was "is it useful to return null?" like $null | ConvertTo-Json | Should -Be $null
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Well, if we want to change that behavior, we should change the code here. JsonObject.ConvertToJson returns null only if StopException is thrown, and it has nothing to do with enabling $null | ConvertTo-Json.
Yeah, $null | ConvertTo-Json seems like a reasonable scenario, but the test should be $null | ConvertTo-Json | Should -Be "null". It's better to discuss this in a separate issue. Can you open an issue?
PS:30> [Newtonsoft.Json.JsonConvert]::SerializeObject($null) -eq "null"
True
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Can you open an issue?
I think Mark Kraus (@markekraus) could comment. If he will confirm that the scenario is useful we'll open new issue.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
You never want ConvertTo-Json write $null to the pipeline. But looking at this, the only scenario that would do that is a stopping exception. I'm not sure if there is any edge case where JsonConvert.SerializeObejct() would return a null string object, nothing I have tried to create such a scenario works anyway. It may be safe to remove it, but, I think it's safer to leave it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Mark Kraus (@markekraus) Thanks!
Dongbo Wang (@daxian-dbw) I think we need a test for $null | ConvertTo-Json.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
$null | ConvertTo-Json is not supported today -- the passed-in $null is ignored. Whether or not we should change the current behavior to support it should be a separate issue.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| return obj; | ||
|
|
||
| return dict; | ||
| cancellationSource.Cancel(); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Should we add tests for this?
(I'd not want.)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
It would be difficult to mimic 'ctrl+c' in the test. I have manually tested it though :)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Steve Lee (@SteveL-MSFT) added such tests previously and they looks tricky. I don't like this but should ask :-)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
There is already a test for StopProcessing in test\powershell\Modules\Microsoft.PowerShell.Utility\ConvertTo-Json.Tests.ps1. It is not currently working perfectly, see #8645.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
See also: #8593
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Thanks xtqqczze , I will take a look at those two PRs.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
…lic API (PowerShell#8682) We have the public API `JsonObject.ConvertFromJson` to convert from JSON string in the PowerShell context. It would be good to have a public API for conversion to JSON. This PR refactors the `ConvertTo-Json` cmdlet to move the core implementation to `JsonObject.ConvertToJson`, and make `ConvertTo-Json` call that public method. This would help the Azure Function PowerShell worker. Currently, we depends on [calling the cmdlet](https://github.com/Azure/azure-functions-powershell-worker/blob/729710d2595b4b96abd4fa5a5547fe880e98bfa6/src/PowerShell/PowerShellManager.cs#L198-L205) to convert object to JSON which is expensive. Once we have the public method `JsonObject.ConvertToJson` exposed, we can call the API directly to avoid a command invocation.
…lic API (PowerShell#8682) We have the public API `JsonObject.ConvertFromJson` to convert from JSON string in the PowerShell context. It would be good to have a public API for conversion to JSON. This PR refactors the `ConvertTo-Json` cmdlet to move the core implementation to `JsonObject.ConvertToJson`, and make `ConvertTo-Json` call that public method. This would help the Azure Function PowerShell worker. Currently, we depends on [calling the cmdlet](https://github.com/Azure/azure-functions-powershell-worker/blob/729710d2595b4b96abd4fa5a5547fe880e98bfa6/src/PowerShell/PowerShellManager.cs#L198-L205) to convert object to JSON which is expensive. Once we have the public method `JsonObject.ConvertToJson` exposed, we can call the API directly to avoid a command invocation. # Conflicts: # test/Test.Common.props
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
Expose ConvertToJson as an API
There was an error while loading. Please reload this page.