Why does Salesforce has Trigger.isInsert or Trigger.isUpdate when Trigger.old !=Null would have worked?
Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap
Example:
We always use it in below scenarios:
Scenarios 1:
if(Trigger.isInsert){
method1();
}
Scenarios 2:
if(Trigger.old == null){
method1();
}
In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?
trigger triggercontext
add a comment |
Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap
Example:
We always use it in below scenarios:
Scenarios 1:
if(Trigger.isInsert){
method1();
}
Scenarios 2:
if(Trigger.old == null){
method1();
}
In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?
trigger triggercontext
add a comment |
Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap
Example:
We always use it in below scenarios:
Scenarios 1:
if(Trigger.isInsert){
method1();
}
Scenarios 2:
if(Trigger.old == null){
method1();
}
In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?
trigger triggercontext
Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap
Example:
We always use it in below scenarios:
Scenarios 1:
if(Trigger.isInsert){
method1();
}
Scenarios 2:
if(Trigger.old == null){
method1();
}
In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?
trigger triggercontext
trigger triggercontext
asked Nov 14 '18 at 20:09
Sandeep Kamlesh MishraSandeep Kamlesh Mishra
213
213
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.
Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
add a comment |
There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.
Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write
if (Trigger.isInsert) {
rather than
if (Trigger.new != null && Trigger.old == null) {
In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like
switch on (Trigger.operationType) {
when BEFORE_INSERT {
// do stuff...
}
when AFTER_UPDATE {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationTypebut now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 '18 at 20:22
add a comment |
You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.
Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.
Trigger.old Returns a list of the old versions of the sObject records.
This sObject list is only available in update and delete triggers.
Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239403%2fwhy-does-salesforce-has-trigger-isinsert-or-trigger-isupdate-when-trigger-old%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.
Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
add a comment |
First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.
Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
add a comment |
First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.
Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.
First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.
Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.
answered Nov 14 '18 at 20:18
Adrian Larson♦Adrian Larson
108k19115244
108k19115244
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
add a comment |
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
– Carl
Nov 15 '18 at 3:36
add a comment |
There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.
Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write
if (Trigger.isInsert) {
rather than
if (Trigger.new != null && Trigger.old == null) {
In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like
switch on (Trigger.operationType) {
when BEFORE_INSERT {
// do stuff...
}
when AFTER_UPDATE {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationTypebut now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 '18 at 20:22
add a comment |
There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.
Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write
if (Trigger.isInsert) {
rather than
if (Trigger.new != null && Trigger.old == null) {
In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like
switch on (Trigger.operationType) {
when BEFORE_INSERT {
// do stuff...
}
when AFTER_UPDATE {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationTypebut now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 '18 at 20:22
add a comment |
There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.
Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write
if (Trigger.isInsert) {
rather than
if (Trigger.new != null && Trigger.old == null) {
In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like
switch on (Trigger.operationType) {
when BEFORE_INSERT {
// do stuff...
}
when AFTER_UPDATE {
// ...
}
// ...
}
There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.
Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write
if (Trigger.isInsert) {
rather than
if (Trigger.new != null && Trigger.old == null) {
In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like
switch on (Trigger.operationType) {
when BEFORE_INSERT {
// do stuff...
}
when AFTER_UPDATE {
// ...
}
// ...
}
answered Nov 14 '18 at 20:18
David ReedDavid Reed
35.7k72154
35.7k72154
1
I was going to add in something abouttrigger.operationTypebut now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 '18 at 20:22
add a comment |
1
I was going to add in something abouttrigger.operationTypebut now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 '18 at 20:22
1
1
I was going to add in something about
trigger.operationType but now that you have it here, I'll leave my answer as is.– Adrian Larson♦
Nov 14 '18 at 20:22
I was going to add in something about
trigger.operationType but now that you have it here, I'll leave my answer as is.– Adrian Larson♦
Nov 14 '18 at 20:22
add a comment |
You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.
Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.
Trigger.old Returns a list of the old versions of the sObject records.
This sObject list is only available in update and delete triggers.
Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm
add a comment |
You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.
Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.
Trigger.old Returns a list of the old versions of the sObject records.
This sObject list is only available in update and delete triggers.
Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm
add a comment |
You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.
Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.
Trigger.old Returns a list of the old versions of the sObject records.
This sObject list is only available in update and delete triggers.
Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm
You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.
Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.
Trigger.old Returns a list of the old versions of the sObject records.
This sObject list is only available in update and delete triggers.
Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm
answered Nov 14 '18 at 20:16
Pranay JaiswalPranay Jaiswal
16.8k32755
16.8k32755
add a comment |
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239403%2fwhy-does-salesforce-has-trigger-isinsert-or-trigger-isupdate-when-trigger-old%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown