Table of Contents
Introduction
Salesforce has a multitenant architecture due to which it has introduced Governor Limits in which Users share the applications and database. Governor Limits are nothing but rules and regulations put by the salesforce for the equal usage of resources. We get a different numbers of Governor Limits synchronously and asynchronously.
What Is Salesforce Multitenancy?
Salesforce is a multitenant environment means each and every organization using Salesforce exists on the same cloud. They all are consuming resources on the common instance of the Salesforce Cloud. In a multi-tenant environment, each and every user shares the same version and infrastructure of the force.com platform. Force.com is a Platform As A Service(PAAS) with the help of which we can develop applications on top of the salesforce.
What Are Salesforce Governor Limits?
We have equal usage or sharing of resources in Salesforce with the help of GOVERNOR LIMITS. So to prevent any organization from using or eating up more resources, Salesforce has introduced the concept of Governor Limits. In this, Salesforce has put the limits on the usage of resources beyond which if any organization tries to consume resources will be thrown with exceptions.
Types Of Salesforce Governor Limits
We have multiple types of Governor Limits in Salesforce mentioned below:
- Per-Transaction Apex Governor Limits
- Per-Transaction Certified Managed Package Limits
- Lightning Platform Apex Limits
- Static Apex Limits
- Size-Specific Apex Limits
Why Are Salesforce Governor Limits Important?
Governor Limits ensure the effective and efficient usage of resources on the Force.com multitenant environment. Hence, we have Governor Limits in place in Salesforce cloud.
If any user is trying to consume more resources in comparison to what they have been assigned or if user hits the Governor Limit, then runtime exception will be thrown that can’t be handled
Governor Limit Best Practices
There are many Governor Limits that should be adhered to in order to prevent any runtime exception.
We can do this in various ways:
1. One of the most common exceptions which users get while writing apex code is SOQL 101 Limit Exception.
System.LimitException: Too many SOQL queries: 101.
So, to avoid this, we should never write SOQL queries inside for loop as we can have 100 SOQL queries per transaction.
SOQL is written inside the for loop. For loop runs repeatedly. So, for e.g., if we insert 1000 records from Data Loader, then for loop will run 1000 times and since SOQL is present in for loop, it will run till 100 and when it comes to 101 records, we get SOQL 101 exception.
2. There is another exception that we should try to avoid which is DML 151.
System.LimitException: Too many DML statements: 151.
Now, this error comes up due to the DML statements in for loop.
We have a Governor Limit of 150 DML statements in a single transaction. If we exceed the number of DML statements per transaction which is more than 150, then we get Too many DML Statements exceptions.
To avoid this, don’t write DML statements in for loop.
MAKE YOUR CODE BULKY !!!
So that it has a similar behavior for both, for single records and for multiple records.
Governor Limits Practice Examples
1. We can improve the below code.
//BAD PRACTICE – DML 151 EXCEPTION
List<Opportunity> oppList = [Select Id, Name, StageName, StageName FROM Opportunity LIMIT 250];
for(Integer i=0; i< oppList.size(); i++){
Opportunity opps = new Opportunity(Name='Test Opp ' + i, StageName='Qualification', closeDate=Date.today()));
insert opps;
}
//GOOD PRACTICE or IMPROVED VERSION OF CODE
List<Opportunity> oppList = [Select Id, Name, StageName, StageName FROM Opportunity LIMIT 250];
List<Opportunity> opps = new List<Opportunity>();
for(Integer i=0; i< oppList.size(); i++){
opps.add(new Opportunity(Name='Test Opp ' + i, StageName='Qualification', closeDate=Date.today()));
}
insert opps;
2. //BAD PRACTICE IN TRIGGER– SOQL 101 EXCEPTION
trigger AccNameDuplicacy on Account(before insert, before update){
for(Account acc : Trigger.new){
List<Account> accList = [SELECT Id, Name FROM Account
WHERE Name =: acc.Name];
if(accList.size() > 0){
acc.addError('Duplicate Name in Account');
}
}
}
//GOOD PRACTICE
trigger AccountNameDuplicacy on Account (before insert, before update) {
Set<String> accNames = new Set<String>();
for(Account acc : Trigger.new){
accNames.add(acc.Name);
}
List<Account> acc = [SELECT Id, Name FROM Account WHERE Name IN :accNames];
Map<String, Account> accMap = new Map<String, Account>();
for(Account acc : acc){
accMap.put(acc.Name, acc);
}
if(acc.size() > 0){
for(Account ac : Trigger.new){
if(ac.Name != null && Trigger.isInsert || (Trigger.isUpdate && Trigger.oldMap.get(ac.Id).Name != ac.Name)){
if(accMap.containsKey(ac.Name)){
ac.Name.addError('Duplicate Name in Account');
}
}
}
}
}
0 Comments