Say you include a schema from a dependency that has a mapping like this:
%% @doc an amazing configuration setting that I promise
%% will never not have 10 as a sensible default!
{mapping, "variable.a", "erlang.term", [
{default, 10},
{datatype, integer}
]}.
So, of course, for your application, 10 is a terrible default. Before you would have to copy this whole mapping into your project's schema and just change the default, but now, you can choose a smart merge:
well, the actual mapping will have the new default of 10000 AND all other attributes of the original mapping, which in this case means {datatype, integer} and importantly, the docs from the original schema will be preserved, so your effective mapping would look like this:
%% @doc an amazing configuration setting that I promise
%% will never not have 10 as a sensible default!
{mapping, "variable.a", "erlang.term", [
{default, 10000},
{datatype, integer}
]}.
Unfortunately, as a consequence of choosing to have mapping be a 4-tuple, you'll need to provide the erlang mapping (in this case "erlang.term") again. Whatever you put in the 3rd element here WILL override the original erlang mapping.
Dat smart merge.
How's it work?
Say you include a schema from a dependency that has a mapping like this:
So, of course, for your application, 10 is a terrible default. Before you would have to copy this whole mapping into your project's schema and just change the default, but now, you can choose a smart merge:
So wha happen?
well, the actual mapping will have the new default of 10000 AND all other attributes of the original mapping, which in this case means
{datatype, integer}
and importantly, the docs from the original schema will be preserved, so your effective mapping would look like this:Unfortunately, as a consequence of choosing to have
mapping
be a 4-tuple, you'll need to provide the erlang mapping (in this case"erlang.term"
) again. Whatever you put in the 3rd element here WILL override the original erlang mapping.