Feature Request #3141
Config merging should treat non-associative array elelemts as unique
| Status: | Closed | Start date: | 07/31/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 100% |
||
| Category: | Core | |||
| Target version: | v3.3.0 | |||
| Resolution: | fixed | Points: |
Description
Problem:¶
Consider the following two config files:
modules/my_module/config/my_file.php
return array(
'servers' => array(
array('1.1.1.1', 4730),
),
);
application/config/my_file.php
return array(
'servers' => array(
array('2.2.2.2', 4730),
),
);
When these are merged, I would expect the end result to look like so:
return array(
'servers' => array(
array('1.1.1.1', 4730),
array('2.2.2.2', 4730),
),
);
What currently (and I believe incorrectly) happens is this:
return array(
'servers' => array(
array(
array('1.1.1.1', 4730),
array('2.2.2.2', 4730),
),
),
);
This happens because both the server/port settings have a key of '0'.
Workaround:¶
Add an unnecessary descriptive key like so:
return array(
'servers' => array(
'1.1.1.1' => array('1.1.1.1', 4730),
),
);
Proposed Solution:¶
Treat non-associative arrays as always unique and ignore their original key. This change would affect the behavior of arr::merge(), ideally this would be added as a parameter.
I believe this change would not affect any of the current stock config files but it may affect users own config files - targeting for 3.1
If people agree - I'll dig in and make the necessary changes.
Related issues
History
Updated by Kiall Mac Innes almost 2 years ago
- Tracker changed from Bug Report to Feature Request
Updated by Jeremy Bush over 1 year ago
- Target version changed from v3.1.0 to v3.2.0
Updated by Jeremy Bush over 1 year ago
This is fundamentally broken because you wouldn't be able to remove system/module level config values. See #3642.
Updated by Woody Gilk over 1 year ago
Updated by Tiger SEO about 1 year ago
Pls fix this, cause it makes problem with extending memcache config
Updated by Jeremy Bush 12 months ago
- Status changed from New to Assigned
- Assignee changed from Woody Gilk to Kiall Mac Innes
Updated by Lorenzo Pisani 11 months ago
The current outcome definitely looks wrong, but I can see uses for both treating non-associative arrays as associative (overwriting) and treating them as unique. But how do you add a parameter to a method that takes any number of arrays? Would you check for the first parameter to be a boolean value?
Apart from that, I think config files should treat all array keys the same. If we use non-associative arrays in config files, they need to be overwritable. I personally think config files should only use associative arrays just for clarity.
Updated by Isaiah DeRose-Wilson 11 months ago
- Target version changed from v3.2.0 to v3.3.0
Updated by Chris Bandy 6 months ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Applied in changeset commit:22e96d301075bdf2c604f39609bf99ab24cc3a87.
Updated by Chris Bandy 6 months ago
- Status changed from Closed to Assigned
- % Done changed from 100 to 0
3.3/issue/3141-merge-indexed-arrays
The first commit adds more tests for existing behavior. The second commit changes behavior for indexed arrays. Faster, in my benchmarks, too.
Updated by Jeremy Bush 5 months ago
- Target version changed from v3.3.0 to Unscheduled
Updated by Chris Bandy 4 months ago
I've opened a proper PR: https://github.com/kohana/core/pull/198
Updated by Kiall Mac Innes 4 months ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
- Resolution set to fixed
Updated by Chris Bandy 4 months ago
- Target version changed from Unscheduled to v3.3.0