function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Possible Bug when Renaming a lookup fied when working in a develpment team

I'm working in a two man dev team - we're using the IDE and each of use have our own dev org. We're using Subclipse for version control. We came across what I think is bug or prehaps we're doing something wrong. Here goes


Dev1 changes the name of a field (Acct to Acc) in a sObject (insurance_policy__c) in his org and syncs the change to his IDE. This field has a lookup relationship with Account called insurance_policies. All changes are checked into svn.


Dev2 gets the latest version from SVN and loads it into his IDE. It sees that the sObject has changes. He then does a Save to Server  - it fails with an error that says that there is already a relationship called insurance_policies. It fails to recognise that only the field name has change and that this not a new field. The only work around is to manually rename the field directly in SF,  or rename the relationship name in the local metadata. The latter results in a new field and new relationships.


During a Save to Server SF should check and compare the incoming metadata and drop the fields that have been removed including relationships and accept the changed field and its relationships or even better just recognise a simple name change.


The Metadata API never implicitly deletes a cutsom field, just because it's missing from a .object file.  To delete a custom field, you must deploy a "destructiveChanges.xml" file (in the same format at package.xml) containing the list of fields (or other components) to delete.


The problem is destructiveChanges removes the entire object ( and the data etc with it), of course you could follow on with the new object in a standard pakage and wrap in an ANT build file but its overkill for a name change. And you then need some way of reloading the data.


In the end the second dev (me) just renamed the offending field to match dev 1.


Perhaps it's not a bug per se but the concept of a modifyPackage.xml would be useful. As it is it's an awkward 'step' in a team envirnoment


I'll stick in Ideas


You can delete just a field (without deleting an entire object) using destructiveChanges.xml.