function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
bikla78bikla78 

APEX code best practice- how to update class and trigger names in production

I have a bunch of class and trigger names I need to update in production. What is the safest way to do this.  Should I clone my production into the sandbox and make sure evertything is in sync. Then, I plan on modifying the class and trigger names in Sandbox and deploy it in Production. 2 questions

 

1. Will this be safe and and will it work?

 

2. If I want to update the class and trigger name in sandbox, how can I do this in eclipse? When I try overwriting the name of the class and the trigger callling the class, i get an error

 

Thanks

Best Answer chosen by Admin (Salesforce Developers) 
ShikibuShikibu
I've run into this problem. The way to understand it is that Eclipse (or ant) uploads stuff that is named in package.xml. The file names must match what's in package.xml. 

You can change the filenames and the content of package.xml. I've found it easier to do that with an editor other than eclipse. For that reason, I have Eclipse's workspace preferences set to always refresh from the disk.
 
However, if you change the names and upload, that will not delete the old class and trigger.  You'll need to delete them manually.
 
Furthermore, if you have test methods in a class required by the trigger that excercise the trigger, the trigger can't be deleted because it depends on methods in the class, and the class can't be deleted or disabled because the trigger depends upon it. 
 
I've found it helpful to either put all the test code into a separate @istest class (see Annotations in the Apex guide), or to have a state  variable in the helper class that tells whether it should test the trigger or not.
 
Then you can either delete the test class, or modify the helper class so it doesn't test the trigger. Then you edit the trigger so it has an empty body, then you delete the helper class.
 
It's a pain. The moral of the story is, get your code organized and tested, and named correctly, before you deploy to a production instance.
 

All Answers

Greg HGreg H

You are correct that the only way to make the updates in your production environment is to make the alterations using a Sandbox or DE org and then deploying them to your production org. It is perfectly safe and the correct way to make the changes you desire. The naming issue within Eclipse where it errors out may be unavoidable. To get around it you may need to add your class and trigger updates to the Sandbox or DE org using the standard user interface (Setup > Develop > Apex Classes, etc) and then refresh your project within Eclipse prior to deploying the code.

-greg
bikla78bikla78

Thanks Greg but when I change the class and trigger names in the sandbox, do I simply just edit the name of the class and the trigger inside the code and press save or is there a section in a eclipse where i change in properties?

 

 
Greg HGreg H

When you use Eclipse to create a new trigger or class you are prompted for the name of that class/trigger and some other details. I believe that Eclipse then stores those properties locally to perform validation on the code prior to pushing it out to Salesforce. I am not aware of a way to alter those properties within Eclipse after the class/trigger is created.

 

However, if you simply log into the DE/Sandbox org and navigate to the class or trigger section, you can click edit next to the code you want to change, retype the name and simply click save. It will apply that name change based on the value stored in the code.

 

Now by making the change in the UI and not in Eclipse you create a disconnect between Eclipse and Salesforce. And because you cannot change the properties of that code within Eclipse you literally need to refresh the trigger folder and class folder in Eclipse.

 

Within Eclipse right click on the folder, choose "Force.com" from the options and then "Refresh from Server" in the subsequent list of options. Eclipse should go out to Salesforce and pull back the triggers/classes with the newest properties based on what is live in the DE org.

-greg
ShikibuShikibu
I've run into this problem. The way to understand it is that Eclipse (or ant) uploads stuff that is named in package.xml. The file names must match what's in package.xml. 

You can change the filenames and the content of package.xml. I've found it easier to do that with an editor other than eclipse. For that reason, I have Eclipse's workspace preferences set to always refresh from the disk.
 
However, if you change the names and upload, that will not delete the old class and trigger.  You'll need to delete them manually.
 
Furthermore, if you have test methods in a class required by the trigger that excercise the trigger, the trigger can't be deleted because it depends on methods in the class, and the class can't be deleted or disabled because the trigger depends upon it. 
 
I've found it helpful to either put all the test code into a separate @istest class (see Annotations in the Apex guide), or to have a state  variable in the helper class that tells whether it should test the trigger or not.
 
Then you can either delete the test class, or modify the helper class so it doesn't test the trigger. Then you edit the trigger so it has an empty body, then you delete the helper class.
 
It's a pain. The moral of the story is, get your code organized and tested, and named correctly, before you deploy to a production instance.
 
This was selected as the best answer