YamlDotNet
YamlDotNet copied to clipboard
Inconsistent behavior with anchors when using .IgnoreUnmatchedProperties() in the deserializer
Describe the bug
When defining anchors on unmatched properties, they cannot be used as-is in properties that are matched. When doing <<: *
, it works. But when doing *
directly, whenever you want to copy everything without overriding, it fails. In my opinion, this should succeed.
You can see the linked repo below for more details. But basically:
Example 1 works:
employees:
- &swdev_30yo
name: John Smith
title: Software Developer
age: 30
- *swdev_30yo
- <<: *swdev_30yo
name: Mary Jane
# This works and creates
# 2 John Smith's and 1 Mary Jane
Example 2 works:
.x: &swdev_30yo
name: John Doe
age: 30
title: Software Developer
employees:
- <<: *swdev_30yo
name: John Smith
- <<: *swdev_30yo
name: Mary Jane
# This works
# .x is ignored, but the anchor can be used below
Example 3 fails
.x: &swdev_30yo
name: John Doe
age: 30
title: Software Developer
employees:
# this syntax fails when the anchor is defined on a property that is ignored
# even though it succeeds in example1, where it is defined on a property that is not ignored
- *swdev_30yo
# this should be OK, based on example2
- <<: *swdev_30yo
name: Mary Jane
# This fails! But I think it should succeed!
# Bug?
I think example 3 should succeed, which is why I'm filing this as a bug. But please correct me if this is intended behavior.
To Reproduce
Please see here: https://github.com/IGkougkousis/yamldotnet-bug-report
Thanks for reporting this, I know it's been a while, but I'm looking in to this now.
Thanks a lot for picking this up! We use yaml and this library extensively in my company, so I'm happy that this project is picking up some steam again.
I'm not familiar with this codebase, but I know C# and I would happy to contribute to this, if possible.
I looked into an issue that was this same one earlier today. #842
Without a large refactor of the parser/scanner and deserializers the anchors need to know the type of the object when encountered. Basically the parser doesn’t support going back to a specified location as it is forward only so it can’t get the object.
since I currently have no intentions on rewriting or heavily modifying the parser I’m going to close this issue.