Open anotherjames opened 7 years ago
@rossb89 you had to handle changing the allowed keys in a list/options field recently, do you have a link to the code that you used to solve that please?
Sadly @anotherjames, my solution won't be appropriate for this. As the data on the site did not matter as we were still in testing land, I think I simply updated the field_data, field_revision tables for the field in question and set the values to NULL..
Hehe oh well, no worries :-)
See https://github.com/computerminds/niquesa/blob/0c876f2e579c5c04d9f9099cf5e21f240daf6c42/webroot/profiles/niquesa_profile/niquesa_profile.install#L359 - this could totally be part of cm_config_tools?
So we could have some event / field-config-changes listener, that checks the field type change, and if it is merely a simple column schema change (and/or even one that adds a column that can be null / has a default?) - see SqlContentEntityStorageSchema::hasColumnChanges() - then we could do just what was done in niquesa_profile_update_8113() - fetch the row values, truncate the table, update the config & last-installed-definition, and re-insert the values.
This would open the way for other special-case handling around 'common' config changes that require extra work, but I think that's ok? A similar case would be around changing the keys in a list field.