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

yaml to struct - merge behavior : deep vs shallow merge #818

Closed
kansalarchit opened this issue Jan 26, 2022 · 1 comment
Closed

yaml to struct - merge behavior : deep vs shallow merge #818

kansalarchit opened this issue Jan 26, 2022 · 1 comment

Comments

@kansalarchit
Copy link

It seems like anchor merge behaves differently depending on the golang struct provided.

With a simple golang interface{} object, the conversion results in shallow merge. e.g.:

top:
  config: &config
    key1: value1
    map1: 
      mapkey1: value1
      mapkey2: value2

  otherconfig:
    <<: *config
    map1:
      mapkey1: some-other-value

results in (Shallow Merge)

top:
  config: &config
    key1: value1
    map1: 
      mapkey1: value1
      mapkey2: value2

  otherconfig:
    key1: value1
    map1:
      mapkey1: some-other-value

whereas when we provide a specific golang struct, such as

type top struct  {
  type config struct {
    key1 string,
    type map1 struct {
      mapkey1 string,
      mapkey2 string
      ...
    }
    ...
  }
  ...
}

For the same input, we get: (Deep Merge)

top:
  config: &config
    key1: value1
    map1: 
      mapkey1: value1
      mapkey2: value2

  otherconfig:
    key1: value1
    map1:
      mapkey1: some-other-value
      mapkey2: value2

This looks like inconsistent behavior and based on https://yaml.org/type/merge.html I believe we should always prefer shallow merge.

Can a flag be added to the parser so that we can choose to ignore deep merge even when parser knows the resulting struct ?

@kansalarchit kansalarchit changed the title yaml to json - merge behavior : deep vs shallow merge yaml to struct - merge behavior : deep vs shallow merge Feb 16, 2022
niemeyer added a commit that referenced this issue May 12, 2022
This addresses a number of related issues on how merge tags
were handled, most notably the case of nested mappings being
merged instead of the outermost value being used as-is.

Closes: #818 #826
@niemeyer
Copy link
Contributor

This and a few more complex cases should have been fixed by 539c8e7.

Please let me know if you see any further issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants