Detect config file renames during the import process. According to comment #2, there are two use cases (in the fields and instances conversion) where the import is not going to detect a rename, of which one is quite problematic.
1. Rename bundle, e.g article to article2: in that case the instance is going to be renamed, e.g field.instance.node.article.field_name.yml to field.instance.node.article2.field_name. The import will detect a delete and a new import. It would be nicer in case this was detected as a rename, but isn't problematic as there's no data loss or so.
2. Deleting a field and recreating a field with the same name. The import will detect this as a change for both the field instance, while it actually should be a delete and a new import. Ironically, we /do/ want data loss here because deleting a field is going to rename the data en revision table so the data in it can be removed later during cron runs.
According to comment #3, we should re-write the config import process to use UUIDs instead of config object names. Or a combination of both (comment #5).
- Write unit test for addChangelistRename()
- Review to determine if this is a duplicate
- Create patch
Original report by heyrocker
Right now, we have no way to handle renamed config. If you rename a config file, it will appear in the import process as the deletion of one file and the creation of another one. This will probably use UUIDs within the config file to determine that this same config just has a different name, rather than being an all new config.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 68,061 pass(es).
[ View ]
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 68,021 pass(es).
[ View ]