X Tutup
The Wayback Machine - https://web.archive.org/web/20220814024659/https://github.com/PowerShell/PowerShell/pull/15545
Skip to content
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

Jump to bottom

Fix for deserializing imported ordered dictionary #15545

Merged
merged 5 commits into from Aug 8, 2022
Merged

Fix for deserializing imported ordered dictionary #15545

merged 5 commits into from Aug 8, 2022
+248 −36

Conversation

davidBar-On
Copy link
Contributor

@davidBar-On davidBar-On commented Jun 8, 2021 •
edited by iSazonov

PR Summary

Suggested fix for issue #2861 - exported ordered dictionary is now imported via Import-Clixml as OrderedDictionary and not as Hashtable. This is done by checking if the imported dictionary type names include type of OrderedDictionary.

PR Context

Fix #2861.

PR Checklist

iSazonov
iSazonov reviewed Jun 10, 2021
View changes
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
src/System.Management.Automation/engine/serialization.cs Outdated Show resolved Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Utility/XMLCommand.Tests.ps1 Outdated Show resolved Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Utility/XMLCommand.Tests.ps1 Outdated Show resolved Hide resolved
@iSazonov iSazonov requested a review from TravisEz13 Jun 10, 2021
@iSazonov iSazonov added the CL-General label Jun 10, 2021
@davidBar-On davidBar-On force-pushed the issue-2861-deserialize-imported-ordered-dictionary branch from 4bcdf6f to d936a79 Compare Jun 10, 2021
@rjmholt rjmholt requested a review from SteveL-MSFT Jun 14, 2021
@msftbot msftbot bot added the Review - Needed label Jun 22, 2021
@msftbot
Copy link

msftbot bot commented Jun 22, 2021

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@daxian-dbw daxian-dbw requested a review from PaulHigin Jul 25, 2022
@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 25, 2022

@PaulHigin can you please take a look at this PR and see the change to serailization.cs is the right fix?

@msftbot msftbot bot removed the Review - Needed label Jul 25, 2022
PaulHigin
PaulHigin requested changes Jul 25, 2022
View changes
Copy link
Collaborator

@PaulHigin PaulHigin left a comment •
edited

These changes look right to me, except that instead of having if/else blocks, I feel it would be cleaner if you created a helper class that encapsulates the dictionary types (Hashtable or OrderedDictionary) and handles adding key/value pairs and re-creating with case sensitive comparer as needed. Something like:

private class PSDictionary
{
    private Hashtable table;
    private OrderedDictionary orderedDictionary;

    public PSDictionary(bool isOrdered) { ... }

    public Add(object key, object value) { ... }

    public object DictionaryObject { get { return _isOrdered ? orderedDictionary : table; } }
}

Also, I think it is fine to compare the type name check to a hard coded constant string: System.Collections.Specialized.OrderedDictionary, instead of getting the full type name from an instance of the object.

@msftbot msftbot bot added the Waiting on Author label Jul 25, 2022
@msftbot msftbot bot removed the Waiting on Author label Aug 5, 2022
@davidBar-On
Copy link
Contributor Author

davidBar-On commented Aug 5, 2022

... instead of having if/else blocks, I feel it would be cleaner if you created a helper class .....

Done

Also, I think it is fine to compare the type name check to a hard coded constant string: System.Collections.Specialized.OrderedDictionary, instead of getting the full type name from an instance of the object.

Did not make the this change, as it seems to me that it safer not to assume the type name. Note that with the other changes FullName is now for the class typeOf and not for a variable.

TravisEz13
TravisEz13 requested changes Aug 5, 2022
View changes
Copy link
Member

@TravisEz13 TravisEz13 left a comment

see comments

@msftbot msftbot bot added the Waiting on Author label Aug 5, 2022
@davidBar-On davidBar-On force-pushed the issue-2861-deserialize-imported-ordered-dictionary branch from 48eae01 to b061f92 Compare Aug 7, 2022
@msftbot msftbot bot removed the Waiting on Author label Aug 7, 2022
@davidBar-On
Copy link
Contributor Author

davidBar-On commented Aug 7, 2022 •
edited

Can you add a test for a key clash? Both kinds

Added test cases for the keys clash. I didn't add them initially as they are not directly related to this PR change.

Most of the added tests I created use a manual "exported" XML, as I did not find a way to create hashtable (ordered or not) that includes duplicate keys, or an ordered hashtable that allows case-sensitive keys. The only added test without using XML is for non-ordered case-sensitive hashtable using New-Object hashtable instead of @{}.

In the added tests I didn't find a way to check which "Comparer" is set for the imported table. Therefore the tests only check the number of elements in the imported table.

Also note that I rewrote the change using the IDictionary interface to simplify the implementation.

@pull-request-quantifier
Copy link

pull-request-quantifier bot commented Aug 8, 2022

This PR has 223 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Large
Size       : +202 -21
Percentile : 62.3%

Total files changed: 2

Change summary by file extension:
.cs : +37 -21
.ps1 : +165 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍  👌  👎 (Email)
Customize PullRequestQuantifier for this repository.

PaulHigin
PaulHigin approved these changes Aug 8, 2022
View changes
Copy link
Collaborator

@PaulHigin PaulHigin left a comment

LGTM

@iSazonov iSazonov merged commit 55c5e78 into PowerShell:master Aug 8, 2022
39 checks passed
@iSazonov
Copy link
Collaborator

iSazonov commented Aug 8, 2022

@davidBar-On Thanks for your contribution!

@msftbot
Copy link

msftbot bot commented Aug 12, 2022

🎉v7.3.0-preview.7 has been released which incorporates this pull request.🎉

Handy links:

@msftbot msftbot bot mentioned this pull request Aug 12, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@TravisEz13 TravisEz13

@SteveL-MSFT SteveL-MSFT

@PaulHigin PaulHigin

@iSazonov iSazonov

Assignees

@iSazonov iSazonov

Labels
CL-General Large
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Deserialized Ordered Dictionary via Import-Clixml is not numerically indexable.
6 participants
@davidBar-On @daxian-dbw @iSazonov @TravisEz13 @SteveL-MSFT @PaulHigin
X Tutup