| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: T166010
Change-Id: I4066885a7ea071d22497abcdb3f95e73e154d08c
|
|
|
|
|
| |
Bug: T278139
Change-Id: If451415b8acbc764b8f2b277dc8635dcfc88ff53
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to keep the actual default values for settings in the same
place as the setting is declared, and applied using the regular means
for loading the settings -- not in a separate piece of code that needs
to be loaded through some entirely different mechanism.
SetupDynamicConfig.php now contains a few categories of things:
* Post-processing of configuration settings, where already-set settings
are altered. This could be moved to MainConfigSchema too as a separate
set of methods.
* Processing of old aliases of settings (blacklist, slave) that are not
registered as settings anymore and therefore are not available to
MainConfigSchema. This could perhaps be moved to LocalSettings
processing somehow?
* Setting $wgUseEnotif, which is also not registered as a setting.
Easiest would be just to declare it as a setting and have it set
unconditionally.
* Setting the actual timezone to $wgLocaltimezone. This is not related
to configuration and should just be in Setup.php.
Bug: T305093
Change-Id: Ia5c23b52dbbfcb3d07ffcf5d3b7f2d7befba2a26
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a modified rebase of a patch by Tim,
see I75f405930a7b14561389c59d147640e870146bec.
Some benchmark results (from my laptop):
Loading defaults from config-schema.php:
- Master: 115/sec ( 8.7ms)
- I75f4059: (Tim): 575/sec ( 1.7ms)
- Id9dd0bf: (Daniel): 1120/sec ( 0.9ms)
- This (Tim+Daniel): 1420/sec ( 0.7ms)
Loading defaults and merging settings (worst case):
- Master: 80/sec (12.4ms)
- I75f4059: (Tim): 93/sec (10.8ms)
- Id9dd0bf: (Daniel): 200/sec ( 4.9ms)
- This (Tim+Daniel): 682/sec ( 1.5ms)
Original commit message by Tim:
* Explicitly import function array_key_exists to activate the special
opcode
* Batch creation of MergeStrategy objects
* Batch default assignment to ArrayConfigBuilder
The batches mostly help by allowing more inlining, eliminating some
function calls.
Reduced time for apply/finalize benchmark from 540µs to 170µs.
Co-Authored-By: Tim Starling <tstarling@wikimedia.org>
Change-Id: I3d4dd685eaaa4351801b3bac6ce1592eea925c5f
|
|
|
|
|
|
|
|
|
| |
When no merge strategies are needed, config values can be set in bulk.
This patch only uses it for config-overrides, but it is intended to be
used for config-schema in a follow-up.
Change-Id: Ic7e62513ad5227887f8a83bb8b757b5667643989
|
|
|
|
|
|
|
| |
The @unstable markers were intended for the 1.38 release.
The interface can be conisdered stable in 1.39.
Change-Id: Ie2fdd5bfe2622aa8845883019c1666dfb3073719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch ensures that we know which arrays are lists (JsonSchema type
"array") and which are maps (JsonSchema type "object"). We can then
default to array_merge for lists and to array_plus for maps. This seems
clearer than requiring an explicit merge strategy to be declared for all
arrays.
This patch specified a mergeTrategy for some config variables that need
behavior different from the default.
This patch also changes the merging behavior to allow non-array values
to replace arrays and vice versa. It also changes the behavior of
defaults to allow falsy values to override non-falsy defaults.
Bug: T300129
Change-Id: Ia7b0c0250af6a957eac1efb554fb47511f5e093f
|
|
|
|
|
| |
Bug: T301544
Change-Id: I0a93ebb5305f95cf1b12df276f25a44195fedafa
|
|
|
|
|
|
|
|
|
|
|
| |
GlobalConfigBuilder needs to use the appropriate merge strategy to
combine new values with the value already rpesent in a global variable.
For this, GlobalConfigBuilder needs to actually look at the current
value of the global variable. Also, we need to define merge strategies
for all settings that need them (at least the ones used directly by
ExtensionProcessor).
Change-Id: I834d4b3506bdd8d416e5eb6e03fb4dd6b60b6e05
|
|
|
|
|
|
|
| |
$this->set was calling the overridden method, so if it was
called from setDefault, we'd end up double-prefixing the config.
Change-Id: I5f912332cc69cb58bb71e87cd9f8154246b53232
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not yet sure if config validation makes sense in production,
possibly before we write into cache we can validate, and then
trust that the cached values are all valid. This patch just
adds ability to validate the configuration.
"justinrainbow/json-schema" is already a transitive dependency
and is already in vendor.
Change-Id: Ib039c897a36a7e1911309fd29514657042b1b139
|
|
|
|
| |
Change-Id: Ibb4fdf83d87ad204da5fbc4892c9b7610e979f72
|
|
The goal is to use SettingsBuilder to load settings from JSON files
instead of relying on PHP files that manipulate global variables.
To allow for a smooth transition to the new system, config settings read
from JSON files will be applied to global variables, and it will be
possible to load JSON files programmatically from inside traditional
settings files.
Bug: T294740
Bug: T295500
Bug: T294741
Change-Id: Ibf52c660715fd0e6e67fea5169811ece9ed67cf7
|