Some changes to the Config system
This is a slight API change. Statics used as config value defaults are now considered immutable after declaration, and any assignment to them will be ignored.
API Make Object::config use late static binding
Can now be used in instance scope, like:
and in static scope, like:
Cache the merged version of any Config value in an in-mem LRU cache
Extract statics via code analysis rather than introspection
Add ability to create temporary Config copies
FIX DataObjectSchemaGenerationTest trying to modify config statics di…
Slight API change enough to warrant going into 3.1 after 2 betas slight?
The underlying issue is that the absence of this patch causes quite serious performance regressions when compared to 2.4.
TLDR; It's pretty slight. I think it should be OK. We might want to do a Beta 3 - Sam?
The basic change is that before, some code might do this to update a config value:
Foo::$some_var = "new value";
That used to work or not work depending on when that code was run & what the config value was. For instance this:
Page::$db = array( .... );
would either work fine or cause errors (or maybe even database corruption) depending on when it's executed.
Now code like that will always be a no-op. You can do anything you like to any static and it won't matter because the static has been extracted before code execution happened.
In master I'll introduce a bigger API change which will deprecate having config values with statics that aren't marked private. That'll make attempts to change config statics throw an error instead of just work silently.
I'll also introduce a freeze method, so that the database layer can do Page::config()->freeze('db') and then any attempt to even do Page::config()->db = .... will cause an error
Page::config()->db = ....
Some micro-optimisations for Config
Can't really say much about the implementation, it's over my head ;)
Hamish, given this should get some exposure before we're getting close to 3.1 final,
I'll recommend that you merge yourself, or get somebody with more insight into the config system to have a look.
But it does need a mention in the upgrading docs first.
Is the loss of caching here okay due to other changes?
Answered my own question; looks good.
I can't see any tests for this? It's the only part of the code that really makes my eyes glaze over; it seems like a pretty key candidate for some unit tests.
Add some tests for the static parser
Remove debug message, any still unexpected token is an error
FIX Avoid get_parent_class in ConfigStaticManifest (was loading all c…
FIX Static polution with informational fields
There's also a test that's currently being skipped (I think it's a MySQL-specific one), since it relies the db config being immutable. Would be good to get that test re-enabled :)
Alright I'm going to merge this and update the upgrade docs.
Followup task: http://open.silverstripe.org/ticket/8317