Page MenuHomePhabricator

Add function to merge 2 arrays by overruling the first
AbandonedPublic

Authored by sascha-egerer on May 15 2014, 3:02 PM.
Tags
None
Referenced Files
F13051580: D9135.id21701.diff
Fri, Apr 19, 3:36 AM
F13051579: D9135.id.diff
Fri, Apr 19, 3:36 AM
Unknown Object (File)
Sat, Apr 13, 11:36 AM
Unknown Object (File)
Sat, Apr 13, 9:53 AM
Unknown Object (File)
Sat, Apr 13, 9:32 AM
Unknown Object (File)
Thu, Apr 11, 8:40 AM
Unknown Object (File)
Thu, Apr 11, 4:48 AM
Unknown Object (File)
Mon, Apr 1, 5:20 PM
Subscribers

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Summary

This is a function to merge 2 arrays into one
array by overruling the values of the first array if the
key is identical.

This is e.g. usefull to merge a global configuration file
with a stage specific configuration.

Test Plan

Check and execute unit tests

Diff Detail

Repository
rPHU libphutil
Branch
master
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 485
Build 485: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

sascha-egerer retitled this revision from to Add function to merge 2 arrays by overruling the first.
sascha-egerer updated this object.
sascha-egerer edited the test plan for this revision. (Show Details)
sascha-egerer added a reviewer: epriestley.

This is e.g. usefull to merge a global configuration file with a stage specific configuration.

Where do you want to use this specifically?

I worry this won't be sufficient in the general case. If both configuration files have lists, sometimes those lists should be combined instead of overwritten, and other times they should be overwritten entirely.

For example, if you're merging .arclint files like this:

{
  "exclude" : ["(^globalstuff/)"]
}

And:

{
  "exclude" : ["(^localstuff/)"]
}

The best way to merge these files is probably to produce ["(^globalstuff/)", "(^localstuff/)"], but this won't do that.

Or, suppose you're merging .arcconfig files like this:

{
  "load": ["a", "b"],
}

And:

{
  "load" : ["z"],
}

...doesn't that produce ["z", "b"], a nonsensical/bizarre result?

In D9135#6, @epriestley wrote:

This is e.g. usefull to merge a global configuration file with a stage specific configuration.

Where do you want to use this specifically?

I worry this won't be sufficient in the general case. If both configuration files have lists, sometimes those lists should be combined instead of overwritten, and other times they should be overwritten entirely.

Yes, it would not work with arrays that have no or numerical keys like in you example.

We have a global configuration file for phabricator to configure stuff. That is located in conf/custom/global.conf.php. For each stage of our deployment we have a seperate config file to adjust settings like conf/custom/integration.conf.php which is loaded by the envirement.

global.conf.php
return array(
  'phabricator.show-beta-applications' => true,
  'phabricator.uninstalled-applications' => array(
    'PhabricatorApplicationUIExamples' => false,
    'PhabricatorApplicationXHProf' => false
  )
);

We want to load the global.conf.php and overrule some settings for a stage. Currently we use the + operator to merge the arrays but this will not return the expected result here.
The stage config currently looks like that:

production.conf.php
return array(
  'phabricator.show-beta-applications' => false,
  'phabricator.uninstalled-applications' => array(
    'PhabricatorApplicationUIExamples' => true,
  )
) + phabricator_read_config_file('custom/global.conf.php');

I've just run the unit test cases against +, array_merge, array_merge_recursive and array_merge_recursive_overrule to show the different result. P1142
Do you have a better idea how to handle these configurations?

epriestley edited edge metadata.

I think this implementation is correct, but we don't have any real use cases in libphutil/arcanist/phabricator, because anywhere we might want to merge configuration can be better covered by rules which handle the cases above. So, the code looks fine, but I don't want to put it in the upstream without use cases motivating it.

This revision now requires changes to proceed.May 17 2014, 3:01 AM

As already said in IRC I'll implement this function with a custom script and abondon this revision.