Apex Code Development You need to sign in to do that
Don't have an account?
Justin Porter Delete Trigger After Update
Hello World!
Reservation is an object that stores demographic information, which has 2 master-details to Features and Hotels, which contain items for each reservation. When a reservation is updated (from dataloader, usually 2k+ a time), I want the Features and Hotels children to be deleted, since new records will be uploaded after reservations. The following trigger is what I have, but I have a feeling it's not "bulkified" because I'm getting errors that IDs are already in the process when upserting via dataloader. Can someone help me "bulkify" this or let me know where I went wrong? Thanks!
(PS - Reservation_Number__c is the lookup to Reservation on each object).
Reservation is an object that stores demographic information, which has 2 master-details to Features and Hotels, which contain items for each reservation. When a reservation is updated (from dataloader, usually 2k+ a time), I want the Features and Hotels children to be deleted, since new records will be uploaded after reservations. The following trigger is what I have, but I have a feeling it's not "bulkified" because I'm getting errors that IDs are already in the process when upserting via dataloader. Can someone help me "bulkify" this or let me know where I went wrong? Thanks!
(PS - Reservation_Number__c is the lookup to Reservation on each object).
trigger ReservationsRemoveChildren on Reservation__c (after update) {
List<Reservation__c> reservations = new List<Reservation__c>{};
Set<Id> ids = new Set<Id>();
for(Reservation__c r : Trigger.new) {
delete [SELECT Id from Feature__c where Reservation_Number__c IN :ids];
delete [SELECT Id from Hotel__c where Reservation_Number__c in :ids];
}
}
Please find the modified code:
trigger ReservationsRemoveChildren on Reservation__c (after update) { Set<Id> validIdSet = new Set<Id>(); for(Reservation__c res: Trigger.new) { if(res.Action_TimeStamp__c != Trigger.oldMap.get(res.Id).Action_TimeStamp__c) { validIdSet.add(res.Id); } } if(!validIdSet.isEmpty()) { delete [SELECT Id from Feature__c where Reservation_Number__c IN :validIdSet]; delete [SELECT Id from Hotel__c where Reservation_Number__c IN :validIdSet]; } }Best Practices for writing the Triggers:
1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts
2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.
3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers
4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.
5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception
6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits
7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore
8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found
9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
Please do let me know if it helps you.
Regards,
Mahesh
All Answers
Please find the below code:
Here I considered:
(1) Bulkified the Trigger.
trigger ReservationsRemoveChildren on Reservation__c (after update) { delete [SELECT Id from Feature__c where Reservation_Number__c IN :Trigger.newMap.keySet()]; delete [SELECT Id from Hotel__c where Reservation_Number__c in :Trigger.newMap.keySet()]; }Please do let me know if it helps you.
Regards,
Mahesh
How can I add in there that I only want the trigger to run if the field Action_TimeStamp__c has changed?
Please find the modified code:
trigger ReservationsRemoveChildren on Reservation__c (after update) { Set<Id> validIdSet = new Set<Id>(); for(Reservation__c res: Trigger.new) { if(res.Action_TimeStamp__c != Trigger.oldMap.get(res.Id).Action_TimeStamp__c) { validIdSet.add(res.Id); } } if(!validIdSet.isEmpty()) { delete [SELECT Id from Feature__c where Reservation_Number__c IN :validIdSet]; delete [SELECT Id from Hotel__c where Reservation_Number__c IN :validIdSet]; } }Best Practices for writing the Triggers:
1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts
2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.
3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers
4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.
5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception
6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits
7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore
8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found
9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
Please do let me know if it helps you.
Regards,
Mahesh