Hi Raj, It is true that native hash merging has its own limitations which would lead to data duplication in some cases. But we need to analyze the trade-off between data duplication against readability and trace-ability aspects. IMHO, it's okay to have few data duplication if it makes things more simple and less error prone.
My concern is that what if this accidentally leads to unexpected data merging? I understand that native merging will merge the top level keys as well, but that is less susceptible for human errors compared to N-level deep merge. Also have a look at Puppet official docs about deep merging [1]. Looks like it is mainly intended for complex data structures and converting them to Puppet resources. We can ask the users to create their own Hiera data structures with deeper merging if they are comfortable with it. But given the additional complexity involved in configuring and installing deep_merge library [2], shall we ship native merge data structures by default? [1] https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera [2] https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera Thanks. On Fri, Dec 25, 2015 at 10:45 AM, Rajkumar Rajaratnam <[email protected]> wrote: > Hi Devs, > > We are using *Native* hash merge right now. *It merges only the top-level > keys and values in each source hash. If the same key exists in both a lower > priority source and a higher priority source, the higher priority value > will be used. *But it doesn't allow us to override a nested hash. > > Lets take an example, > > *hiera.yaml* > > --- > :hierarchy: > - "wso2/%{::product_name}/%{::product_version}/default" > - wso2/common > :backends: > - yaml > :yaml: > :datadir: "hieradata/%{::environment}" > > *wso2/common.yaml* > > --- > # Deployment synchronization configuration > wso2::dep_sync : > enabled : false > auto_checkout : true > auto_commit : false > repository_type : svn > svn : > url : http://svnrepo.example.com/repos/ > user : username > password : password > append_tenant_id: true > > *wso2/wso2esb/4.9.0/default.yaml* > > --- > wso2::dep_sync : > enabled : true > svn : > url : http://rajkumar.com/repos/ > > > *Native* hash merge would return the following; > > { > "enabled" =>true, > "auto_checkout" =>true, > "auto_commit" =>false, > "repository_type" =>"svn", > "svn" => { > "url" =>"http://rajkumar.com/repos/"; > } > } > > *Deeper* hash merge would return the following; > > { > "enabled" =>true, > "auto_checkout" =>true, > "auto_commit" =>false, > "repository_type" =>"svn", > "svn" => { > "url" =>"http://rajkumar.com/repos/";, > "user" =>"username", > "password" =>"password", > "append_tenant_id" =>true > } > } > > > If we use *Native* hash merging, we need to copy the complete nested hash > ("svn" in above example) and override it. If we use *Deeper* hash > merging, we can copy only a part of a nested hash and override it. As you > can see, *Deeper* hash merge reduces data duplication. > > Thoughts please. > > Thanks, > Raj. > > -- > Rajkumar Rajaratnam > Committer & PMC Member, Apache Stratos > Software Engineer, WSO2 > > Mobile : +94777568639 > Blog : rajkumarr.com > -- Akila Ravihansa Perera WSO2 Inc.; http://wso2.com/ Blog: http://ravihansa3000.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
