You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that the interpretation of the specification for merge is different than other parsers (PyYAML, JS-YAML, SnakeYAML), and in my opinion incorrect (although I do happen to rely on it for some "features").
I have found that when merging a single mapping node into a target mapping, values for keys that are present in that source mapping and had previously been declared in the target mapping are overriding the existing ones. Other parsers' interpretation of the spec is that values in the source mapping should be completely ignored:
If the value associated with the key is a single mapping node, each of its key/value pairs is inserted into the current mapping, unless the key already exists in it
I ran into this when bumping from v1 to v2, which resulted in a slightly changed behavior when the source value is a mapping but not the target one (in that particular case, going in the direction of other parsers' interpretation, but breaking a behavior I had taken for granted).
Tests exhibiting the current v2 behavior against the expected one are available at bjaglin@3697451:
anchors:
list:
- &FOO { empty: notreally, flat: false, nested: { foo: merged } }
# All the following maps should be equal:
plain:
empty:
flat: true
nested:
foo: foo
bar: bar
mergeBefore:
<< : *FOO
empty:
flat: true
nested:
foo: foo
bar: bar
mergeAfter:
empty:
flat: true
nested:
foo: foo
bar: bar
<< : *FOO
It seems that the interpretation of the specification for merge is different than other parsers (PyYAML, JS-YAML, SnakeYAML), and in my opinion incorrect (although I do happen to rely on it for some "features").
I have found that when merging a single mapping node into a target mapping, values for keys that are present in that source mapping and had previously been declared in the target mapping are overriding the existing ones. Other parsers' interpretation of the spec is that values in the source mapping should be completely ignored:
I ran into this when bumping from v1 to v2, which resulted in a slightly changed behavior when the source value is a mapping but not the target one (in that particular case, going in the direction of other parsers' interpretation, but breaking a behavior I had taken for granted).
Tests exhibiting the current v2 behavior against the expected one are available at bjaglin@3697451:
The text was updated successfully, but these errors were encountered: