Issues with using ArrayAccess for config

[uaktags]

We were moving towards using file based config because the mysql scheme was a bit complex and confusing to look at. However, I've found a number of reasons why I still prefer the db version to the current ArrayAccess method of having config listed in multiple files as simple arrays.

1) Can't traverse over an ArrayAccess or see what's inside it via common array functions. For instance, simple foreach methods, array_keys, etc are out which are useful for printing out what the ArrayAccess contains.

2) You can't edit and save the configs back to the original array file, which means any changes you make to the cache will get removed the moment the cache needs to be rebuilt (like on a module install)

3) Due to pt2, you can't create any sort of GUI for working the configs. This wouldn't be a problem if all the configs were in the same location, but we have /config, /core/config, and /modules/*/config to consider. Try finding what you're looking for and making the edit. It's pretty bad.

Basically as long as there's no way to write back the results in a way that will persist cache rebuilds and the structure of configs continues to be spread out, I can't think of how this can be any better than the old MySQL structure.

I'll push a branch of what it takes to even get a simple output which finally works, but again, there's no save ability.

[ferdis]

So I'd suggest using a proper configuration format here, like YAML/JSON/INI. This can easily be read and written via an external(composer) library.

On the caching side, I think it may pose to be more work than it's worth. The fs will do caching for you in most cases, so that you don't need to hold one in-memory yourself. Leaving it to the fs also allows for more granularity.

[uaktags]

I think the problem isn't as simple as being able to read/write the configs, it's the fact that configs can have so many files that make up the whole lot. The non-array methods like those above solve the ability to do modification, but only if the config originates from a single entity. Spread across multiple files, you're back into the same issue of not knowing where the update needs to be saved to unless we eliminate the idea that modules can add additional directives to other Configuration groups. So each config file would have to be it's own separate group.

/core/config/app.<ext> 'app'=> 'setting1' = 'value1', ... /config/database.<ext> 'database'=> 'db_host' = 'localhost', ... /module/Bank/config.<ext> 'bank'=> 'setting1'= 'value1' ... So no module/other config file can be able to add a new subgroup created by another config, or else you lose the file's save location. This is in contrast to the old method of having 1 config file to initialize the db and then the DB becomes the sole Save/Update point.

---

As for the "caching" aspect, imo it's important to limit the need for searching for configs every time you load. Otherwise you're always going to have a file search for configs to be loaded rather than just loading a single compiled file as I'd presume that'll greatly slow things down and bog the server over time with visitors.

[deohnas]

For me, I don't see these to be in any particular issues. Configuration are in some way "static", even though they can be changed in runtime, but not persistently which is fine. If you want to change a configuration, just open the file and resave.

Regarding the hierarchy, the core config should never be changed by the User, neither should the module configuration. These are "base" configuration, that the User changes / overrides in their config/ folder.