deep merging #62

Open
brewster1134 opened this Issue May 2, 2012 · 7 comments

Comments

Projects
None yet
7 participants

i noticed you cannot deep merge keys.

defaults: &defaults
  parent:
    nested_one: foo
    nested_two: bar

development:
  <<: *defaults
  parent:
    nested_one: bar

returns:

defaults:
  parent:
    nested_one: foo
    nested_two: bar
development:
  parent:
    nested_one: bar

but i was expecting:

defaults:
  parent:
    nested_one: foo
    nested_two: bar
development:
  parent:
    nested_one: bar
    nested_two: bar       # this key would exist in a proper deep merge

the yaml specs dont really cover how it is should work, but is there a deep merging solution? if it should deep merge, i can update the psych test specs.

I expected the same thing and am now looking for a workaround.

This would be a great feature, I think. One could, for instance, extend the syntax so it's backwards-compatible:

# Merging in just one level
<<: *defaults

# Merging in recursively
<<: **defaults

What do you think?

bump
this causes me lots of config headaches.

Owner

tenderlove commented Sep 10, 2013

@ingydotnet do you have any opinions on how (or if) this should work?

The double-asterisk @remofritzsche proposed seems like a clean backwards compatible way of handling this use case.

First off, hash merging is one of those YAML things that is not clearly defined. It is actually in the realm of things that I don't think YAML should define. It's just a loader behavior that could be accomplished in a number of ways.

In general, a yaml loader, configged a certain way is pretty much free to interpret any YAML input, as any native memory object. The default loader config should should be as close as possible to a (cyclical) JSON-model graph.

So in terms of Psych, I think that enabling loader functionality (like merging at all), should be plugin based and not a default. However I can guess that is not practical. I would at least start towards this pattern.

Using **defaults unquoted, is a YAML 1.2, parse error. So you should pick some other syntax for the plugin to key on.

<<<: *recursive-defaults       # comes to mind

It may not be perfectly backwards compatable, But then it's not on by default.

bmedici commented Jun 8, 2016

Any news about that? In a YAML-based configuration system, we'll need this kind of recursive merge. What is the right way to use
<<: *defaults
to have defaults values merged into the receiving section ?
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment