YamlDotNet icon indicating copy to clipboard operation
YamlDotNet copied to clipboard

Inconsistent behavior with anchors when using .IgnoreUnmatchedProperties() in the deserializer

Open IGkougkousis opened this issue 2 years ago • 2 comments

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

IGkougkousis avatar Feb 25 '22 16:02 IGkougkousis

Thanks for reporting this, I know it's been a while, but I'm looking in to this now.

EdwardCooke avatar Jul 26 '22 05:07 EdwardCooke

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.

IGkougkousis avatar Jul 28 '22 14:07 IGkougkousis

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.

EdwardCooke avatar Sep 01 '23 20:09 EdwardCooke