settings-store/symfony-config: assume default config if none found, and migration implementation idea #15704
StefanRickli
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This has some overlap with #15155.
I am trying to have
config_location
set tosettings-store
for all scopes in my dev environment, and be able to have a clean, working state afterpimcore-install
, with a custom set of bundles preinstalled, and with 'factory'-defaults preloaded (use case:git clone
of my project for testing of clean state). Currently, as the settings-store is empty after thesetup_database
installation step, the application simply crashes after installation.As far as I saw in the code, solving this would require either the installer to write a default config (for bundles that require a preexisting one) into the settings-store, or
LocationAwareConfigRepository
to return a default config if it doesn't find one at the specified location.Option 1: Installer should instate defaults in settings-store
I would prefer this solution as it wouldn't influence any existing runtime behavior. I already made a PoC hack that replicates
SystemSettingsConfig::get()
andAdminConfig::get()
with forced loading from the container config that then saves to the settings-store, and it seems to work, if injected after thesetup_database
step.Option 2: Repository should fall back to other config_location if load returns empty
However, if the latter path is chosen, the fix could lead to a potential solution for #15155 as well because at least in my view, I would expect Pimcore to automatically migrate settings between yaml and settings-store when I change a config_location.
That means, if
LocationAwareConfigRepository::loadConfigByKey()
should load from the settings-store but can't find it, the function could fall back trying to load from the container config. On the next save, the anomaly is fixed and an implicit migration done.The same applies to the other direction.
Probably the main difficulty for a migration solution is the cleanup. We wouldn't want the old configuration to linger around. But since a configuration value can be defined in multiple yaml files (and symfony merges them), it is hard to decide which configuration lines or files to remove. Am I correct?
Beta Was this translation helpful? Give feedback.
All reactions