Renaming field name ends with ADD/MOD and DELETE.
Steps to reproduce:
The result:
package.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Test__c.abc__c</members>
<name>CustomField</name>
</types>
<version>50.0</version>
</Package>
destructiveChanges.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Test__c.ABC__c</members>
<name>CustomField</name>
</types>
<version>50.0</version>
</Package>
git diff:
R084 force-app/main/default/objects/Test__c/fields/ABC__c.field-meta.xml force-app/main/default/objects/Test__c/fields/abc__c.field-meta.xml
So, in spite of the fact that even sfdx cannot handle the name changing properly (push/pull) there should be only the change in the package.xml not in destructivechanges.xml.
Interesting issue, thank you for reporting it @MaciekLeks!
@scolladon my 2 cents on this one:
First, I agree with @MaciekLeks that in this very particular scenario (renamed field where nothing changed but the letter case), the field should not be part of the destructive package.
But I'd say it's usually a bad practice to change the letter case in the API name of an existing field, because, by definition, the API name is the primary key for the metadata (so a metadata deployment is not meant to "update" it).
As mentioned, you will run into issues if you try to update the API name via the source or mdapi commands. The safest way to fix the API name would be a destruction of the previous field, and a re-creation with the correct name.
This is just to say that, IMHO, this situation should occur rarely, and will most likely involve some level of manual intervention anyway.
But still, I agree that it would be nice not to have the metadata in the destructive package if only the letter case is changed, because that's a situation where it's not up to the CI/CD pipeline to perform a deletion (it will likely be dealt with manually).
Hi guys!
Interesting issue! I agree (as always with @mehdisfdc 馃槃) it is a very edge case which should not occur but when it does it could be fancy to handle it!
IMHO it is the continuity of #107
I'll develop the feature soon
@MaciekLeks I'm sorry I cannot put the tag "Good first issue", even if it is a very good description of issue, and only because it does not follow the issue template. That said, it allowed me to understand very fast the issue and how to reproduce it, thank you.
Most helpful comment
Interesting issue, thank you for reporting it @MaciekLeks!
@scolladon my 2 cents on this one:
First, I agree with @MaciekLeks that in this very particular scenario (renamed field where nothing changed but the letter case), the field should not be part of the destructive package.
But I'd say it's usually a bad practice to change the letter case in the API name of an existing field, because, by definition, the API name is the primary key for the metadata (so a metadata deployment is not meant to "update" it).
As mentioned, you will run into issues if you try to update the API name via the
sourceormdapicommands. The safest way to fix the API name would be a destruction of the previous field, and a re-creation with the correct name.This is just to say that, IMHO, this situation should occur rarely, and will most likely involve some level of manual intervention anyway.
But still, I agree that it would be nice not to have the metadata in the destructive package if only the letter case is changed, because that's a situation where it's not up to the CI/CD pipeline to perform a deletion (it will likely be dealt with manually).